[
  {
    "path": ".devcontainer/devcontainer.json",
    "content": "{\n  \"name\": \"keda-docs\",\n  \"image\": \"mcr.microsoft.com/devcontainers/javascript-node:24\",\n  \"features\": {\n    \"ghcr.io/devcontainers-community/features/deno\": {}\n  },\n  \"postCreateCommand\": \"npm install\"\n}\n"
  },
  {
    "path": ".editorconfig",
    "content": "root = true\n\n[*]\nend_of_line = lf\n\n[Makefile]\nindent_style = tab\n\n[*.{html,js,json,md,sass,toml,yaml}]\nindent_style = space\nindent_size = 2\n\n[*.{js,json,md,sass,toml,yaml}]\ninsert_final_newline = true\n"
  },
  {
    "path": ".gitattributes",
    "content": "# normalize all introduced text files to LF line endings (recognized by git)\n *           text=auto\n # additionally declare text file types\n *.sh        text eol=lf\n"
  },
  {
    "path": ".github/CODEOWNERS",
    "content": "# General owners\n*                      @kedacore/keda-docs\n# HTTP Add-on\ncontent/http-add-on/   @kedacore/keda-http-maintainers @kedacore/keda-docs\n# KEDA core\ncontent/docs/          @kedacore/keda-core-maintainers @kedacore/keda-docs\n"
  },
  {
    "path": ".github/PULL_REQUEST_TEMPLATE.md",
    "content": "<!-- Thank you for contributing!\n\n     Read more about how you can contribute in our contribution guide:\n     https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md\n-->\n\n_Provide a description of what has been changed_\n\n### Checklist\n\n- [ ] Commits are signed with Developer Certificate of Origin (DCO)\n\nFixes #\n"
  },
  {
    "path": ".github/renovate.json5",
    "content": "{\n  $schema: \"https://docs.renovatebot.com/renovate-schema.json\",\n  extends: [\n    // See https://docs.renovatebot.com/presets-config/#configbest-practices\n    \"config:best-practices\",\n    \"customManagers:githubActionsVersions\",\n    \"schedule:monthly\",\n    \":gitSignOff\",\n    \":prHourlyLimitNone\",\n  ],\n  commitBodyTable: true,\n  labels: [\"dependencies\"],\n  // Experimental: OSV-based vulnerability alerts for direct dependencies\n  osvVulnerabilityAlerts: true,\n  postUpdateOptions: [\"npmDedupe\"],\n  packageRules: [\n    {\n      matchManagers: [\"github-actions\"],\n      groupName: \"GitHub Actions\",\n    },\n    {\n      matchManagers: [\"npm\"],\n      matchUpdateTypes: [\"minor\", \"patch\"],\n      groupName: \"npm Dependencies (non-major)\",\n    },\n    {\n      matchFileNames: [\".devcontainer/**\"],\n      pinDigests: false,\n    },\n  ],\n  vulnerabilityAlerts: {\n    enabled: true,\n    addLabels: [\"security\"],\n  },\n}\n"
  },
  {
    "path": ".github/reviewers.yml",
    "content": "# https://github.com/marketplace/actions/auto-assign-reviewer-by-files\n\"**/*\":\n  - team: keda-docs\n\n# Any datadog.md file\n\"**/datadog.md\":\n  - team: keda-core-datadog-notification"
  },
  {
    "path": ".github/workflows/auto-assign.yml",
    "content": "name: Auto Assign\non:\n  - pull_request_target\n\njobs:\n  assign_reviewer:\n    runs-on: ubuntu-slim\n    steps:\n      - uses: shufo/auto-assign-reviewer-by-files@0a7fae44d02e841755d0caaac2ef05ad12a3bbc9 # v1.2.1\n        with:\n          config: \".github/reviewers.yml\"\n          token: ${{ secrets.GH_AUTOMATION_PAT }}\n"
  },
  {
    "path": ".github/workflows/check-links.yml",
    "content": "# Adapted from @chalin's work on https://github.com/chalin/docsy-starter\n\nname: Links\n\non:\n  merge_group:\n  pull_request:\n  push: { branches: [main] }\n\njobs:\n  build-and-check-links:\n    name: BUILD and CHECK LINKS\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6\n\n      - uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6\n        with:\n          node-version-file: .nvmrc\n          cache: npm\n\n      - run: npm install --omit=optional\n\n      - run: npm run check:links\n\n"
  },
  {
    "path": ".github/workflows/pr-bot-welcome.yml",
    "content": "name: PR Welcome Bot\n\non:\n  pull_request_target:\n    types: [opened]\n    branches:\n    - 'main'\n\npermissions:\n  issues: write\n  pull-requests: write\n\njobs:\n  pr_bot:\n    name: PR Bot\n    runs-on: ubuntu-slim\n    steps:\n      - name: 'Comment on PR'\n        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9\n        with:\n          github-token: ${{ secrets.GITHUB_TOKEN }}\n          script: |\n            await github.rest.issues.createComment({\n              owner: context.repo.owner,\n              repo: context.repo.repo,\n              issue_number: ${{ github.event.number }},\n              body: 'Thank you for your contribution! 🙏 We will review your PR as soon as possible.\\n\\n\\n> While you are waiting, make sure to:\\n\\n\\n- Add your contribution to all applicable KEDA versions\\n- GitHub checks are passing\\n- Is the DCO check failing? Here is [how you can fix DCO issues](https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md#i-didnt-sign-my-commit-now-what)\\n\\n\\nLearn more about:\\n- How to become a [listed end-user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) or a [listed commerical offering](https://github.com/kedacore/keda-docs#become-a-listed-keda-commercial-offering)\\n- Our [contribution guide](https://github.com/kedacore/keda-docs/blob/main/CONTRIBUTING.md)'\n            });\n"
  },
  {
    "path": ".github/workflows/stale.yml",
    "content": "name: \"Stale\"\n\non:\n  schedule:\n    - cron: \"0 2 * * *\"\n  workflow_dispatch:\n\npermissions:\n  actions: write\n  issues: write\n  pull-requests: write\n\njobs:\n  stale:\n    runs-on: ubuntu-slim\n    steps:\n      - uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10\n        with:\n          days-before-stale: 60\n          days-before-close: 7\n          operations-per-run: 30\n\n          # Issues\n          exempt-issue-labels: \"cant-touch-this,feature,security\"\n          stale-issue-label: \"stale\"\n          stale-issue-message: >\n            This issue has been automatically marked as stale because it has not had\n            recent activity. It will be closed in 7 days if no further activity occurs. Thank you\n            for your contributions.\n          close-issue-message: >\n            This issue has been automatically closed due to inactivity.\n\n          # PRs\n          exempt-pr-labels: \"cant-touch-this,feature,security\"\n          stale-pr-label: \"stale\"\n          stale-pr-message: >\n            This pull request has been automatically marked as stale because it has not had\n            recent activity. It will be closed in 7 days if no further activity occurs. Thank you\n            for your contributions.\n          close-pr-message: >\n            This pull request has been automatically closed due to inactivity.\n"
  },
  {
    "path": ".gitignore",
    "content": "node_modules/\n/public\n.idea\nresources/\n.DS_Store\n.hugo_build.lock\n\n# Link checker artifacts\nbin/\ntmp/\n\n# Local Netlify folder\n.netlify\n"
  },
  {
    "path": ".htmltest.yml",
    "content": "DirectoryPath: public\nEnforceHTTPS: true\nEnforceHTML5: true\nIgnoreDirectoryMissingTrailingSlash: true\nCheckExternal: false\nIgnoreAltMissing: true\nIgnoreEmptyHref: true\nIgnoreURLs:\n  # /latest/ URLs are redirect-only paths handled by Netlify; no static page exists for them\n  - /docs/latest/\n  - /http-add-on/latest/\n  # Temporal ignores\n  # Deprecated and removed resources\n  # Renamed pages\n  - /docs/2.18/scalers/splunk-observability.md/\n"
  },
  {
    "path": ".nvmrc",
    "content": "lts/*\n"
  },
  {
    "path": ".whitesource",
    "content": "{\n  \"scanSettings\": {\n    \"baseBranches\": []\n  },\n  \"checkRunSettings\": {\n    \"vulnerableCheckRunConclusionLevel\": \"failure\",\n    \"displayMode\": \"diff\"\n  },\n  \"issueSettings\": {\n    \"minSeverityLevel\": \"LOW\"\n  }\n}"
  },
  {
    "path": "CONTRIBUTING.md",
    "content": "# Contributing to KEDA\n\nThanks for helping make KEDA better 😍.\n\nThere are many areas we can use contributions - documenting scalers, adding FAQ, troubleshooting, samples, and more.\n\nOur documentation is versioned so it's important to make the changes for the correct KEDA version.\nIf you need to introduce a new version, we recommend reading our documentation about it [here](#working-with-documentation-versions).\n\n- [Contributing to KEDA](#contributing-to-keda)\n  - [Getting Help](#getting-help)\n  - [Local development](#local-development)\n  - [Contributing New Documentation](#contributing-new-documentation)\n    - [Adding blog post](#adding-blog-post)\n    - [Adding scaler documentation](#adding-scaler-documentation)\n    - [Writing documentation for a scaler](#writing-documentation-for-a-scaler)\n    - [Writing documentation for a new authentication provider](#writing-documentation-for-a-new-authentication-provider)\n    - [Add new Frequently Asked Question (FAQ)](#add-new-frequently-asked-question-faq)\n    - [Add new troubleshooting guidance](#add-new-troubleshooting-guidance)\n  - [Working with documentation versions](#working-with-documentation-versions)\n    - [Preparing a new version](#preparing-a-new-version)\n    - [Publishing a new version](#publishing-a-new-version)\n  - [Developer Certificate of Origin: Signing your work](#developer-certificate-of-origin-signing-your-work)\n    - [Every commit needs to be signed](#every-commit-needs-to-be-signed)\n    - [I didn't sign my commit, now what?](#i-didnt-sign-my-commit-now-what)\n  - [Changing the website](#changing-the-website)\n    - [Adding a new filter option](#adding-a-new-filter-option)\n  - [Listing KEDA Users and Commercial Offerings](#listing-keda-users-and-commercial-offerings)\n    - [Become a listed KEDA user](#become-a-listed-keda-user)\n    - [Become a listed KEDA commercial offering](#become-a-listed-keda-commercial-offering)\n\n## Getting Help\n\nIf you have a question about KEDA or how best to contribute, the [#KEDA](https://kubernetes.slack.com/archives/CKZJ36A5D) channel on the Kubernetes Slack ([get an invite if you don't have one already](https://slack.k8s.io/)) is a good place to start.\nWe also have regular [community stand-ups](https://github.com/kedacore/keda#community) to track ongoing work and discuss areas of contribution.\nFor any issues with the product you can [create an issue](https://github.com/kedacore/keda/issues/new) in this repo.\n\n## Local development\n\n1. Fork and clone this repository.\n2. Install [Node](https://nodejs.org/).\n   Hugo is bundled via the `hugo-extended` npm package — no separate Hugo install needed.\n3. Install dependencies:\n   ```console\n   npm install\n   ```\n4. Serve the site locally at [localhost:8888](http://localhost:8888):\n   ```console\n   npm run serve\n   ```\n5. To do a one-off build (output goes to `public/`):\n   ```console\n   npm run build\n   ```\n6. To check for broken links (runs a build first):\n   ```console\n   npm run check:links\n   ```\n\n## Contributing New Documentation\n\nWe provide easy ways to introduce new content:\n\n### Adding blog post\n\nTo add a new post to the [KEDA blog](https://keda.sh/blog):\n\n```console\nnpx hugo new blog/my-new-post.md\n```\n\nThis creates a boilerplate Markdown file in `content/blog/my-new-post.md` whose\ncontents you can modify. The following fields are required:\n\n- `title`\n- `date` (in `YYYY-MM-DD` format)\n- `author`\n\n> Note: Please ensure the file is named correctly, as it will be used as the blog post URL slug. Avoid defining an alias to rename the URL slug, as this goes against our convention.\n\n### Adding scaler documentation\n\nTo add documentation for a new KEDA [scaler](https://keda.sh/docs/scalers):\n\n```console\nnpx hugo new --kind scaler docs/<VERSION>/scalers/my-new-scaler.md\n```\n\nThis creates a boilerplate Markdown file in\n`content/docs/<VERSION>/scalers/my-new-scaler.md` whose contents you can modify.\nMake sure to update the following metadata fields:\n\n- `title`\n- `availability`\n- `maintainer`\n- `description`\n\n### Writing documentation for a scaler\n\nIn order to maintain the style consistency across different scalers, all the\nparameters which are listed have to be written using this convention:\n\n- name - Description. (Values: x, y, z, Default: y, Optional, Extra Info)\n\nIf a parameter is required or doesn't have defined/default values, the missing\ninfo should be removed from the pattern.\n\nHere are a few examples:\n\n> - `targetMetricValue` - Target value for your metric.\n> - `metricFilter` - Aggregation method of the metric. (Values: `max`, `min`, `average`, `sum`, `variance`, Default: `average`, Optional)\n> - `metricPeriod` - Granularity of the metric. (Default: `300`, Optional)\n> - `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional, Required when `topicName` is specified)\n\n### Writing documentation for a new authentication provider\n\nTo add documentation for a new [provider](https://keda.sh/docs/concepts/authentication):\n\n```console\nnpx hugo new --kind provider docs/<VERSION>/providers/my-new-provider.md\n```\n\nThis creates a boilerplate Markdown file in\n`content/docs/<VERSION>/providers/my-new-provider.md` whose contents you can modify.\nMake sure to update the following metadata fields:\n\n- `title`\n\n### Add new Frequently Asked Question (FAQ)\n\nTo update the KEDA [FAQ page](https://keda.sh/docs/faq), update the TOML file\nreferenced by `versionData` in `content/docs/<VERSION>/reference/faq.md`.\nHere's an example question/answer pair:\n\n```toml\n[[qna]]\nq = \"How can I add a new question/answer pair?\"\na = \"You're looking at it! 😀\"\n```\n\n### Add new troubleshooting guidance\n\nTo add a new section to the [troubleshooting page](https://keda.sh/docs/troubleshooting):\n\n```console\nnpx hugo new troubleshooting/<VERSION>/my-new-issue.md\n```\n\nTo adjust the order in which the troubleshooting tiles appear, use the `weight`\nparameter in each page's metadata.\n\n## Working with documentation versions\n\nThe KEDA documentation is versioned. Each version has its own subdirectory under\n[content/docs](content/docs). To add a new version, follow these steps:\n\n1. Copy the directory for the most recent version:\n   ```console\n   cp -rf content/docs/<CurrentVersion> content/docs/<NewVersion>\n   ```\n2. Copy the file for the most recent faq data in the `data` directory:\n   ```console\n   cp -rf data/faq<CurrentVersion> data/faq<NewVersion>\n   ```\n3. Update the `versionData` option in `content/docs/<NewVersion>/reference/faq.md`, replacing `NEW_FAQ_FILE_NAME` with the file name of the faq data for the new version:\n   ```text\n   {{< faq20 versionData=\"NEW_FAQ_FILE_NAME\" >}}\n   ```\n\nBy default, new documentation versions are not listed as available version so\nit's safe to make changes to them. After every release, the version will be\npublished as new version.\n\n### Preparing a new version\n\nRemember to create the folder for next version with already existing docs in\ncurrent version.\n\nMake sure that the version on `content/docs/{next-version}/deploy.md` is updated\nand uses the next version, instead of the current one. Ensure that Kubernetes cluster version is updated as well.\n\nEnsure that compatibility matrix on `content/docs/{next-version}/operate/cluster.md` is updated with the compatibilities for the incoming version.\n\nUpdate the new version in the `params.unreleased.docs` list in [hugo.toml](hugo.toml).\n\n### Publishing a new version\n\nOnce a version is ready to be published, we must add the version to the\n`params.versions.docs` list in [hugo.toml](hugo.toml).\n\nMore recent versions should be placed first in the list (ordering _does_ matter\nbecause the first element in that list is considered the latest version).\n\n> Note: Remember to [prepare the next version](#preparing-a-new-version).\n\n## Developer Certificate of Origin: Signing your work\n\n### Every commit needs to be signed\n\nThe Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Here is the full text of the DCO, reformatted for readability:\n\n```text\nBy making a contribution to this project, I certify that:\n\n    (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or\n\n    (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or\n\n    (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.\n\n    (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.\n```\n\nContributors sign-off that they adhere to these requirements by adding a `Signed-off-by` line to commit messages.\n\n```text\nThis is my commit message\n\nSigned-off-by: Random J Developer <random@developer.example.org>\n```\n\nGit even has a `-s` command line option to append this automatically to your commit message:\n\n```console\ngit commit -s -m 'This is my commit message'\n```\n\nEach Pull Request is checked whether or not commits in a Pull Request do contain a valid Signed-off-by line.\n\n### I didn't sign my commit, now what?\n\nNo worries - You can easily replay your changes, sign them and force push them!\n\n```console\ngit checkout <branch-name>\ngit reset $(git merge-base main <branch-name>)\ngit add -A\ngit commit -sm \"one commit on <branch-name>\"\ngit push --force\n```\n\n## Changing the website\n\n### Adding a new filter option\n\nTo add a new filter option, simply follow these steps:\n\n1. Navigate to the doc file you want to annotate.\n2. In the frontmatter, add your new filter option:\n   ```toml\n   FILTER_NAME = \"filter_value\"\n   ```\n   Replace `FILTER_NAME` with any desired name of your choice. Same applies to the value.\n3. In `layouts/_default/list.lunr.json`, just before the closing parenthesis, append your new option:\n   ```text\n   \"FILTER_NAME\" $scalers.Params.FILTER_NAME\n   ```\n4. In `hugo.toml`, in the `params.lunr` section, add your new filter option's name to both arrays:\n   ```toml\n   vars = [\"title\", \"maintainer\", \"description\", \"availability\", \"category\", \"type\", \"FILTER_NAME\"]\n   params = [\"availability\", \"maintainer\", \"category\", \"type\", \"FILTER_NAME\"]\n   ```\n5. In `assets/js/scaler-search.js`, in the `lunr()` callback where `this.field` is called, append your field:\n   ```javascript\n   this.field(\"FILTER_NAME\", {\n     boost: 5,\n   });\n   ```\n   And where `parse[doc.title]` is built, add your field:\n   ```javascript\n   parse[doc.title] = {\n     href: doc.href,\n     title: doc.title,\n     maintainer: doc.maintainer,\n     description: doc.description,\n     availability: doc.availability,\n     category: doc.category,\n     type: doc.type,\n     FILTER_NAME: doc.FILTER_NAME,\n   };\n   ```\n6. In `layouts/partials/scaler-layout.html`, locate the div with class `filter-options` and add this new block:\n   ```html\n   <div class=\"has-extra-top-margin\">\n     <h6>FILTER_NAME</h6>\n     {{ $FILTER_NAME := slice }} {{ range $scalers := where site.RegularPages\n     \".CurrentSection.Title\" \"Scalers\" }} {{ with $scalers.Params.FILTER_NAME }} {{\n     $FILTER_NAME = $categories | append ($scalers.Params.FILTER_NAME) }} {{\n     $FILTER_NAME = uniq $FILTER_NAME }} {{ end }} {{ end }} {{ range $FILTER_NAME\n     }} {{ $item := . }}\n     <div>\n       <input\n         id=\"{{ . }}\"\n         type=\"checkbox\"\n         name=\"resource_filter\"\n         value=\"FILTER_NAME:{{ . }}\"\n       />\n       <label for=\"{{ . }}\">{{ . }}</label>\n     </div>\n     {{ end }}\n   </div>\n   ```\n7. Save your changes and rebuild your frontend.\n\n## Listing KEDA Users and Commercial Offerings\n\n### Become a listed KEDA user!\n\nAre you using KEDA in production? Do you want to become a [listed user](https://keda.sh/community/#users)? Say no more!\n\nYou can easily get listed by following these steps:\n\n1. Upload your logo to `static/img/logos/` _(350x180)_\n2. Configure your company as a new user in `hugo.toml` _(sorted alphabetically)_\n\n```toml\n[[params.users]]\nurl = \"https://coralogix.com/\"\nlogo = \"coralogix.gif\"\n```\n\nHere's a good example of [Coralogix becoming a listed user](https://github.com/kedacore/keda-docs/pull/182)!\n\n### Become a listed KEDA commercial offering!\n\nDo you offer commercial support for KEDA and want to become a [listed commercial offering](https://keda.sh/enterprise)? Say no more!\n\nTo be listed as a KEDA commercial offering, organizations must meet the following criteria:\n\n- Demonstrate a commitment to KEDA's maintenance and improvement.\n  - On average, have pull requests accepted monthly into KEDA or related projects for features and/or improvements.\n  - Have made a substantial contribution to the development of KEDA or related projects.\n  - Help triage and comment on issues across the KEDA ecosystem at least 3 times per month.\n- Demonstrate an area of expertise in the KEDA ecosystem.\n  - Example: Employing one or more KEDA maintainers.\n  - Example: Owning a specific high-impact feature or process.\n- Participate in KEDA's governance.\n  - At least 1 member of the vendor's team attends the community meetings at least 50% of the time.\n- Be active KEDA thought leaders.\n  - Example: Sponsoring staff for KEDA booths or community events.\n  - Example: Giving talks related to KEDA or its ecosystem.\n- Provide enterprise-level support and functionality for KEDA or products based directly on it.\n\nIf any questions arise regarding eligibility, the KEDA maintainers will make the final decision.\n\nIf your organization meets these requirements, you can request to be listed by following these steps:\n\n1. Open a pull request and provide evidence in the PR description showing how the requirements above have been met.\n2. Upload your logo to `static/img/logos/` _(350x180)_\n3. Configure your company as a new vendor in `hugo.toml` _(sorted alphabetically)_\n\n```toml\n[[params.vendors]]\nname = \"Red Hat\"\nlogo = \"vendors/red-hat.png\"\ndescription = \"\"\"\nRed Hat integrates KEDA with OpenShift through the **Custom Metrics Autoscaler** (CMA) available through the OpenShift Marketplace.\n\"\"\"\nurls = [\n  { text = \"Learn more about the CMA\", url = \"https://cloud.redhat.com/blog/custom-metrics-autoscaler-on-openshift\" }\n]\n```\n"
  },
  {
    "path": "LICENSE",
    "content": "\n                                 Apache License\n                           Version 2.0, January 2004\n                        http://www.apache.org/licenses/\n\n   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n   1. Definitions.\n\n      \"License\" shall mean the terms and conditions for use, reproduction,\n      and distribution as defined by Sections 1 through 9 of this document.\n\n      \"Licensor\" shall mean the copyright owner or entity authorized by\n      the copyright owner that is granting the License.\n\n      \"Legal Entity\" shall mean the union of the acting entity and all\n      other entities that control, are controlled by, or are under common\n      control with that entity. For the purposes of this definition,\n      \"control\" means (i) the power, direct or indirect, to cause the\n      direction or management of such entity, whether by contract or\n      otherwise, or (ii) ownership of fifty percent (50%) or more of the\n      outstanding shares, or (iii) beneficial ownership of such entity.\n\n      \"You\" (or \"Your\") shall mean an individual or Legal Entity\n      exercising permissions granted by this License.\n\n      \"Source\" form shall mean the preferred form for making modifications,\n      including but not limited to software source code, documentation\n      source, and configuration files.\n\n      \"Object\" form shall mean any form resulting from mechanical\n      transformation or translation of a Source form, including but\n      not limited to compiled object code, generated documentation,\n      and conversions to other media types.\n\n      \"Work\" shall mean the work of authorship, whether in Source or\n      Object form, made available under the License, as indicated by a\n      copyright notice that is included in or attached to the work\n      (an example is provided in the Appendix below).\n\n      \"Derivative Works\" shall mean any work, whether in Source or Object\n      form, that is based on (or derived from) the Work and for which the\n      editorial revisions, annotations, elaborations, or other modifications\n      represent, as a whole, an original work of authorship. For the purposes\n      of this License, Derivative Works shall not include works that remain\n      separable from, or merely link (or bind by name) to the interfaces of,\n      the Work and Derivative Works thereof.\n\n      \"Contribution\" shall mean any work of authorship, including\n      the original version of the Work and any modifications or additions\n      to that Work or Derivative Works thereof, that is intentionally\n      submitted to Licensor for inclusion in the Work by the copyright owner\n      or by an individual or Legal Entity authorized to submit on behalf of\n      the copyright owner. For the purposes of this definition, \"submitted\"\n      means any form of electronic, verbal, or written communication sent\n      to the Licensor or its representatives, including but not limited to\n      communication on electronic mailing lists, source code control systems,\n      and issue tracking systems that are managed by, or on behalf of, the\n      Licensor for the purpose of discussing and improving the Work, but\n      excluding communication that is conspicuously marked or otherwise\n      designated in writing by the copyright owner as \"Not a Contribution.\"\n\n      \"Contributor\" shall mean Licensor and any individual or Legal Entity\n      on behalf of whom a Contribution has been received by Licensor and\n      subsequently incorporated within the Work.\n\n   2. Grant of Copyright License. Subject to the terms and conditions of\n      this License, each Contributor hereby grants to You a perpetual,\n      worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n      copyright license to reproduce, prepare Derivative Works of,\n      publicly display, publicly perform, sublicense, and distribute the\n      Work and such Derivative Works in Source or Object form.\n\n   3. Grant of Patent License. Subject to the terms and conditions of\n      this License, each Contributor hereby grants to You a perpetual,\n      worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n      (except as stated in this section) patent license to make, have made,\n      use, offer to sell, sell, import, and otherwise transfer the Work,\n      where such license applies only to those patent claims licensable\n      by such Contributor that are necessarily infringed by their\n      Contribution(s) alone or by combination of their Contribution(s)\n      with the Work to which such Contribution(s) was submitted. If You\n      institute patent litigation against any entity (including a\n      cross-claim or counterclaim in a lawsuit) alleging that the Work\n      or a Contribution incorporated within the Work constitutes direct\n      or contributory patent infringement, then any patent licenses\n      granted to You under this License for that Work shall terminate\n      as of the date such litigation is filed.\n\n   4. Redistribution. You may reproduce and distribute copies of the\n      Work or Derivative Works thereof in any medium, with or without\n      modifications, and in Source or Object form, provided that You\n      meet the following conditions:\n\n      (a) You must give any other recipients of the Work or\n          Derivative Works a copy of this License; and\n\n      (b) You must cause any modified files to carry prominent notices\n          stating that You changed the files; and\n\n      (c) You must retain, in the Source form of any Derivative Works\n          that You distribute, all copyright, patent, trademark, and\n          attribution notices from the Source form of the Work,\n          excluding those notices that do not pertain to any part of\n          the Derivative Works; and\n\n      (d) If the Work includes a \"NOTICE\" text file as part of its\n          distribution, then any Derivative Works that You distribute must\n          include a readable copy of the attribution notices contained\n          within such NOTICE file, excluding those notices that do not\n          pertain to any part of the Derivative Works, in at least one\n          of the following places: within a NOTICE text file distributed\n          as part of the Derivative Works; within the Source form or\n          documentation, if provided along with the Derivative Works; or,\n          within a display generated by the Derivative Works, if and\n          wherever such third-party notices normally appear. The contents\n          of the NOTICE file are for informational purposes only and\n          do not modify the License. You may add Your own attribution\n          notices within Derivative Works that You distribute, alongside\n          or as an addendum to the NOTICE text from the Work, provided\n          that such additional attribution notices cannot be construed\n          as modifying the License.\n\n      You may add Your own copyright statement to Your modifications and\n      may provide additional or different license terms and conditions\n      for use, reproduction, or distribution of Your modifications, or\n      for any such Derivative Works as a whole, provided Your use,\n      reproduction, and distribution of the Work otherwise complies with\n      the conditions stated in this License.\n\n   5. Submission of Contributions. Unless You explicitly state otherwise,\n      any Contribution intentionally submitted for inclusion in the Work\n      by You to the Licensor shall be under the terms and conditions of\n      this License, without any additional terms or conditions.\n      Notwithstanding the above, nothing herein shall supersede or modify\n      the terms of any separate license agreement you may have executed\n      with Licensor regarding such Contributions.\n\n   6. Trademarks. This License does not grant permission to use the trade\n      names, trademarks, service marks, or product names of the Licensor,\n      except as required for reasonable and customary use in describing the\n      origin of the Work and reproducing the content of the NOTICE file.\n\n   7. Disclaimer of Warranty. Unless required by applicable law or\n      agreed to in writing, Licensor provides the Work (and each\n      Contributor provides its Contributions) on an \"AS IS\" BASIS,\n      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or\n      implied, including, without limitation, any warranties or conditions\n      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\n      PARTICULAR PURPOSE. You are solely responsible for determining the\n      appropriateness of using or redistributing the Work and assume any\n      risks associated with Your exercise of permissions under this License.\n\n   8. Limitation of Liability. In no event and under no legal theory,\n      whether in tort (including negligence), contract, or otherwise,\n      unless required by applicable law (such as deliberate and grossly\n      negligent acts) or agreed to in writing, shall any Contributor be\n      liable to You for damages, including any direct, indirect, special,\n      incidental, or consequential damages of any character arising as a\n      result of this License or out of the use or inability to use the\n      Work (including but not limited to damages for loss of goodwill,\n      work stoppage, computer failure or malfunction, or any and all\n      other commercial damages or losses), even if such Contributor\n      has been advised of the possibility of such damages.\n\n   9. Accepting Warranty or Additional Liability. While redistributing\n      the Work or Derivative Works thereof, You may choose to offer,\n      and charge a fee for, acceptance of support, warranty, indemnity,\n      or other liability obligations and/or rights consistent with this\n      License. However, in accepting such obligations, You may act only\n      on Your own behalf and on Your sole responsibility, not on behalf\n      of any other Contributor, and only if You agree to indemnify,\n      defend, and hold each Contributor harmless for any liability\n      incurred by, or claims asserted against, such Contributor by reason\n      of your accepting any such warranty or additional liability.\n\n   END OF TERMS AND CONDITIONS\n\n   APPENDIX: How to apply the Apache License to your work.\n\n      To apply the Apache License to your work, attach the following\n      boilerplate notice, with the fields enclosed by brackets \"[]\"\n      replaced with your own identifying information. (Don't include\n      the brackets!)  The text should be enclosed in the appropriate\n      comment syntax for the file format. We also recommend that a\n      file or class name and description of purpose be included on the\n      same \"printed page\" as the copyright notice for easier\n      identification within third-party archives.\n\n   Copyright 2020 The KEDA Authors.\n\n   and others that have contributed code to the public domain.\n\n   Licensed under the Apache License, Version 2.0 (the \"License\");\n   you may not use this file except in compliance with the License.\n   You may obtain a copy of the License at\n\n       http://www.apache.org/licenses/LICENSE-2.0\n\n   Unless required by applicable law or agreed to in writing, software\n   distributed under the License is distributed on an \"AS IS\" BASIS,\n   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n   See the License for the specific language governing permissions and\n   limitations under the License."
  },
  {
    "path": "MAINTAINERS.md",
    "content": "# Kubernetes Event-driven Autoscaling (KEDA) Maintainers\n\nYou can find a recent update of the maintainers [here](https://github.com/kedacore/governance/blob/main/MEMBERS.md).\n"
  },
  {
    "path": "Makefile",
    "content": "HTMLTEST_DIR=tmp\nHTMLTEST?=htmltest # Specify as make arg if different\nHTMLTEST_ARGS?=--skip-external\n\nDOCS=public/docs\nLATEST_VERSION=$(shell grep -e '^docs' hugo.toml | grep -oe '[0-9][0-9]*.[0-9][0-9]' | head -1)\nHTTP_ADDON_LATEST_VERSION=$(shell grep -e '^http-add-on' hugo.toml | grep -oe '[0-9][0-9]*.[0-9][0-9]' | head -1)\n\n# Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy\nifeq (, $(shell which $(HTMLTEST)))\noverride HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest\nifeq (, $(shell which $(HTMLTEST)))\nGET_LINK_CHECKER_IF_NEEDED=get-link-checker\nendif\nendif\n\ncheck-links: $(GET_LINK_CHECKER_IF_NEEDED) make-redirects-for-checking\n\t$(HTMLTEST) $(HTMLTEST_ARGS)\n\tfind public/* -type l -ls -exec rm -f {} \\;\n\nmake-redirects-for-checking:\n\t@if [ -z $(LATEST_VERSION) ]; then \\\n\t\techo \"Failed to extract LATEST_VERSION. Cannot setup symlinks for checking\"; \\\n\t\texit 1; \\\n\tfi\n\t@if [ -z $(HTTP_ADDON_LATEST_VERSION) ]; then \\\n\t\techo \"Failed to extract HTTP_ADDON_LATEST_VERSION. Cannot setup symlinks for checking\"; \\\n\t\texit 1; \\\n\tfi\n\t@echo \"Creating symlinks of 'latest' to $(LATEST_VERSION) for the purpose of link checking\"\n\t(cd public && rm -f scalers && ln -s docs/$(LATEST_VERSION)/scalers scalers)\n\t(cd public/docs && rm -f latest && ln -s $(LATEST_VERSION) latest)\n\t(cd public/http-add-on && rm -f latest && ln -s $(HTTP_ADDON_LATEST_VERSION) latest)\n\nget-link-checker:\n\trm -Rf $(HTMLTEST_DIR)/bin\n\tcurl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin\n\nclean:\n\trm -rf $(HTMLTEST_DIR) public/* resources\n"
  },
  {
    "path": "README.md",
    "content": "# KEDA - Docs\n\nDocumentation and landing page for the KEDA project at [keda.sh][].\n\n- [Become a listed KEDA user!](CONTRIBUTING.md#become-a-listed-KEDA-user)\n- [Become a listed KEDA commercial offering!](CONTRIBUTING.md#become-a-listed-KEDA-commercial-offering)\n\n## Contributing\n\nWe welcome issues and PRs! For details, see [Contributing to KEDA][].\n\nIf you submit a PR, Netlify will automatically create a [deploy preview][] so\nthat you can view your changes. Once merged, Netlify automatically deploys to\nthe production site [keda.sh][].\n\nTo see deploy logs and more, visit project's [dashboard][] -- Netlify login\nrequired.\n\n[Contributing to KEDA]: CONTRIBUTING.md\n[dashboard]: https://app.netlify.com/sites/keda\n[deploy preview]: https://www.netlify.com/blog/2016/07/20/introducing-deploy-previews-in-netlify/\n[keda.sh]: https://keda.sh\n"
  },
  {
    "path": "archetypes/blog.md",
    "content": "+++\ntitle = \"{{ replace .Name \"-\" \" \" | title }}\"\ndate = {{ dateFormat \"2006-01-02\" .Date }}\nauthor = \"Scaley McAutoscaler\"\n+++\n"
  },
  {
    "path": "archetypes/provider.md",
    "content": "+++\ntitle = \"{{ replace .Name \"-\" \" \" | title }}\"\n+++\n\nAuthentication provider description.\n\n```yaml\ncode\n```\n"
  },
  {
    "path": "archetypes/scaler.md",
    "content": "+++\ntitle = \"{{ replace .Name \"-\" \" \" | title }}\"\navailability = \"\"\nmaintainer = \"\"\ndescription = \"Insert description here\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `*Scaler Type*` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n  - type: *Scaler Type*\n    metadata:\n      namespace: SYS.ELB\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Endpoint to verify the identity against.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n*Provide an example of how to configure the trigger, preferably using TriggerAuthentication*\n"
  },
  {
    "path": "archetypes/troubleshooting.md",
    "content": "+++\ntitle = \"Replace this with a question\"\n+++\n\nAnd provide the answer here...\n"
  },
  {
    "path": "assets/js/alpine.js",
    "content": "import Alpine from \"alpinejs\";\n\nwindow.Alpine = Alpine;\nAlpine.start();\n"
  },
  {
    "path": "assets/js/docsearch.js",
    "content": "import docsearch from \"@docsearch/js\";\nimport * as params from \"@params\";\n\nfunction meta(name) {\n  const element = document.querySelector(`meta[name=\"docsearch:${name}\"]`);\n  return element ? element.content : \"\";\n}\n\nconst currentTag = meta(\"tag\");\nconst currentProduct = meta(\"product\");\n\n// Each tag encodes product + version in one value (e.g. \"docs-2.19\").\n// This avoids needing a cross-attribute filter like (product AND version)\n// which Algolia's filter syntax does not support in OR groups.\nconst tags = {\n  docs: \"docs-\" + params.latestDocs,\n  \"http-add-on\": \"http-add-on-\" + params.latestHttpAddon,\n};\nif (currentProduct in tags && currentTag) {\n  tags[currentProduct] = currentTag;\n}\n\nconst facetFilters = Object.values(tags)\n  .map((tag) => \"tag:\" + tag)\n  .concat(\"tag:blog\");\n\ntry {\n  docsearch({\n    apiKey: params.apiKey,\n    appId: params.appId,\n    indices: [\n      {\n        name: params.indexName,\n        searchParameters: { facetFilters: [facetFilters] },\n      },\n    ],\n    container: \"#navbar-search\",\n    insights: true,\n  });\n} catch (err) {\n  console.error(\"DocSearch failed to initialize:\", err);\n}\n"
  },
  {
    "path": "assets/js/scaler-search.js",
    "content": "import lunr from \"lunr\";\n\nwindow.addEventListener(\"DOMContentLoaded\", () => {\n  \"use strict\";\n\n  const input = document.getElementById(\"search-input\");\n  if (!input) return;\n\n  let index;\n  let debounceTimer;\n  const currentUrl = window.location.pathname;\n  const currentLocation = String(currentUrl).split(\"/\");\n  const currentVersion = currentLocation[2];\n  const form = document.getElementById(\"search\");\n  const target = document.querySelector(\".is-search-result\");\n  const filterIcon = document.querySelector(\".filter-icon\");\n  const filterOptions = document.querySelector(\".filter-options\");\n  const searchResultCount = document.querySelector(\".results\");\n  const template = document.getElementById(\"is-search-template\");\n  const interval = 500;\n  let query = input.value.trim();\n  let parse = {};\n  let searchQueue = [];\n  let checkboxes = document.querySelectorAll('input[name=\"resource_filter\"]');\n\n  // fetch all scalers on initial load\n  if (!query) {\n    initSearchIndex();\n  }\n\n  // logic for input search\n  input.addEventListener(\n    \"input\",\n    function (event) {\n      event.preventDefault();\n      clearTimeout(debounceTimer);\n      const keywords = input.value.trim();\n\n      query = keywords;\n\n      debounceTimer = setTimeout(initSearchIndex, interval);\n\n      // clear out all the scaler item card during search\n      while (target.firstChild.nextSibling) {\n        target.removeChild(template.nextSibling.nextElementSibling);\n      }\n    },\n    false,\n  );\n\n  // logic for category filter\n  checkboxes.forEach((checkbox) => {\n    checkbox.addEventListener(\"change\", function (event) {\n      if (checkbox.checked) {\n        const inputValue = event.target.value.split(\" \");\n        // for single queries with spacing, use the first word\n        const inputQuery = inputValue[0];\n        searchQueue.push(inputQuery);\n        query = searchQueue.join(\" \");\n        initSearchIndex();\n      }\n\n      if (!checkbox.checked) {\n        const inputValue = event.target.value.split(\" \");\n        // for single queries with spacing, use the first word\n        const inputQuery = inputValue[0];\n        searchQueue = searchQueue.filter((word) => word != inputQuery);\n        query = searchQueue.join(\" \");\n        initSearchIndex();\n      }\n\n      // clear out all the scaler item card during search\n      while (target.firstChild.nextSibling) {\n        target.removeChild(template.nextSibling.nextElementSibling);\n      }\n    });\n  });\n\n  // show filter options on mobile\n  filterIcon.addEventListener(\"click\", function () {\n    if (filterOptions.style.display === \"none\" || filterOptions.style.display === \"\") {\n      filterOptions.style.display = \"flex\";\n    } else {\n      filterOptions.style.display = \"none\";\n    }\n  });\n\n  async function initSearchIndex() {\n    const builtInScalers = await fetch(\"/index.json\", { method: \"GET\" })\n      .then((response) => response.json())\n      .then((data) => {\n        return data;\n      })\n      .catch((err) => console.error(\"error:\", err));\n\n    const externalScalerUrl =\n      \"https://artifacthub.io/api/v1/packages/search?offset=0&limit=20&facets=false&kind=8&deprecated=false&sort=relevance\";\n    const externalScalersData = await fetch(externalScalerUrl)\n      .then((response) => response.json())\n      .then((data) => {\n        return data.packages;\n      })\n      .catch((err) => console.error(\"error:\", err));\n\n    const externalScalers = (externalScalersData || []).map((scaler) => ({\n      type: \"external\",\n      availability: `v${scaler.version}+`,\n      title: scaler.display_name,\n      maintainer:\n        scaler.repository.organization_name ?? scaler.repository.user_alias,\n      href:\n        \"https://artifacthub.io/packages/keda-scaler/\" +\n        scaler.repository.name +\n        \"/\" +\n        scaler.normalized_name,\n      version: currentVersion,\n      description: scaler.description,\n      category: null,\n    }));\n\n    const scalers = [...(builtInScalers || []), ...externalScalers];\n\n    index = lunr(function () {\n      const documents = scalers;\n\n      this.ref(\"title\");\n      this.field(\"title\", {\n        boost: 20,\n        usePipeline: true,\n        wildcard: lunr.Query.wildcard.TRAILING,\n        presence: lunr.Query.presence.REQUIRED,\n      });\n      this.field(\"maintainer\", {\n        boost: 15,\n      });\n      this.field(\"href\", {\n        boost: 15,\n      });\n      this.field(\"description\", {\n        boost: 10,\n      });\n      this.field(\"availability\", {\n        boost: 5,\n      });\n      this.field(\"category\", {\n        boost: 10,\n      });\n      this.field(\"type\", {\n        boost: 20,\n      });\n\n      documents.forEach(function (doc) {\n        if (doc.version === currentVersion) {\n          this.add(doc);\n          parse[doc.title] = {\n            href: doc.href,\n            title: doc.title,\n            maintainer: doc.maintainer,\n            description: doc.description,\n            availability: doc.availability,\n            category: doc.category,\n            type: doc.type,\n          };\n        }\n      }, this);\n    });\n\n    search(query);\n  }\n\n  function search(keywords) {\n    // show all scalers by default\n    let queryString = index.search(\"\");\n\n    /* Lunr only matches complete words by default. If an exact match fails,\n    retry with a trailing wildcard to support prefix matching. */\n    if (keywords.length > 0) {\n      queryString = index.search(keywords);\n      queryString =\n        queryString.length <= 0 ? index.search(`${keywords}*`) : queryString;\n    }\n\n    const results = queryString;\n\n    if (\"content\" in template) {\n      // show result count\n      const title = document.createElement(\"h3\");\n      title.id = \"search-results\";\n      title.className = \"subtitle is-size-3\";\n\n      if (results.length == 0) title.textContent = `No results found`;\n      else if (results.length == 1) title.textContent = `Found 1 result`;\n      else if (results.length > 1 && keywords === \"\")\n        title.textContent = `${results.length} scalers available`;\n      else title.textContent = `Found ${results.length} results`;\n      searchResultCount.replaceChildren(title);\n\n      // show the matched result\n      results.forEach(function (result) {\n        const doc = parse[result.ref];\n        const element = template.content.cloneNode(true);\n        element.querySelector(\".badge\").textContent = doc.type;\n        element.querySelector(\".scaler-title\").textContent = doc.title;\n        element.querySelector(\".scaler-title\").setAttribute(\"href\", doc.href);\n        if (doc.type === \"external\") {\n          element.querySelector(\".badge\").style.color = \"purple\";\n        }\n        if (doc.description) {\n          element.querySelector(\".description\").textContent = doc.description;\n        }\n        if (doc.maintainer) {\n          element.querySelector(\".maintainer\").textContent = doc.maintainer;\n        }\n        if (doc.availability) {\n          element.querySelector(\".availability\").textContent = doc.availability;\n        }\n        target.appendChild(element);\n      }, this);\n    }\n  }\n});\n"
  },
  {
    "path": "assets/js/site.js",
    "content": "// Anchor link scroll offset — compensates for the fixed navbar.\nconst navbar = document.getElementsByClassName(\"navbar\")[0];\nconst navbarHeight = navbar ? navbar.offsetHeight : 0;\nconst extraPadding = 15;\nconst navbarOffset = -1 * (navbarHeight + extraPadding);\nfunction shiftWindow() {\n  scrollBy(0, navbarOffset);\n}\nwindow.addEventListener(\"hashchange\", shiftWindow);\nwindow.addEventListener(\"pageshow\", shiftWindow);\nif (window.location.hash) shiftWindow();\n\n// Copy-to-clipboard for FAQ / troubleshooting permalink buttons.\nfunction copyPermalink(id) {\n  const url = `${window.location.origin}${window.location.pathname}#${id}`;\n  const container = document.getElementById(id);\n  if (!navigator.clipboard) {\n    console.error(\"Clipboard API not available\");\n    return;\n  }\n  navigator.clipboard.writeText(url).then(() => {\n    container.classList.add(\"copy-text-active\");\n    setTimeout(() => container.classList.remove(\"copy-text-active\"), 2500);\n  }, (err) => {\n    console.error(\"Could not copy text:\", err);\n  });\n}\n\nconst copyBtns = document.querySelectorAll(\".copyBtn\");\ncopyBtns.forEach((btn) => {\n  btn.addEventListener(\"click\", (event) => {\n    event.stopPropagation();\n    copyPermalink(btn.getAttribute(\"id\"));\n  });\n});\n\n// Expand collapsed FAQ/troubleshooting section matching the URL hash.\nwindow.addEventListener(\"DOMContentLoaded\", () => {\n  \"use strict\";\n  const hash = window.location.hash.slice(1);\n  const cardContents = document.querySelectorAll(\".card-content-dropdown\");\n  cardContents.forEach((item) => {\n    const id = item.getAttribute(\"id\");\n    if (hash === id) {\n      item.style.display = \"\";\n    } else {\n      item.style.display = \"none\";\n    }\n  });\n});\n"
  },
  {
    "path": "assets/sass/card.sass",
    "content": ".card\n  height: 100%\n  box-shadow: 5px 10px 15px #e4e4e4;\n  border-radius: 5px\n\n  display: flex\n  flex-direction: column\n\n  &.is-dark\n    background-color: $black-bis\n    color: $white-bis\n\n  &-content\n    flex: 1\n\n  &-is-wrapped\n    flex-wrap: wrap\n  \n  &.is-collapsible\n    & + &\n      margin-top: 0.5rem\n"
  },
  {
    "path": "assets/sass/content.sass",
    "content": ".doc-hero\n  margin-bottom: 1.5rem\n\n  .title sup\n    line-height: 0\n\n.content\n  a sup\n    margin-left: 0.1rem\n\n  ol li pre\n    margin-bottom: 1rem\n\n  .highlight\n    margin-bottom: 1rem\n\n  // Allow horizontal scrolling for larger tables\n  table\n    display: block\n    overflow-x: auto\n    max-width: 100%\n\n  &.is-constrained\n    max-width: 90ch\n\n  &.has-bottom-margin\n    margin-bottom: 8rem\n\n  // Headline hashes\n  .headline-hash\n    display: none\n    margin-left: 0.25rem\n    color: $secondary\n\n  @for $i from 1 through 6\n    h#{$i}\n      &:hover > .headline-hash\n        display: inline\n\n  figure img\n    +desktop\n      width: 100%\n\n  @media screen and (min-width: 769px)\n    .is-search-result > .column, .is-external-search-result > .column \n      width: 50%\n"
  },
  {
    "path": "assets/sass/nav.sass",
    "content": "=active\n  font-weight: $weight-bold\n\n  a\n    color: $primary !important\n\n=split-x\n  display: flex\n  flex-direction: row\n  justify-content: space-between\n\n.nav\n  padding-bottom: 2rem\n\n  &-subsection\n    &-title\n      a\n        font-weight: 500\n        color: $dark\n\n      +split-x\n\n      &.is-active\n        +active\n\n  &-section\n    &-title\n      a\n        font-weight: 600\n        color: $dark\n\n      +split-x\n\n      &.is-active\n        +active\n\n  &-section, &-subsection\n    &-toc\n      padding: 0.35rem 0 0.75rem 1rem\n      //padding: 0.75rem 0 0.75rem 1rem\n\n      li a\n        color: $grey\n\n      ul + ul\n        margin-top: 0.3rem\n\n    ul.nav-section-links\n      margin: 0.5rem 0 0.75rem 1rem\n\n      li.nav-section-link\n        font-size: 1.1rem\n\n        a\n          color: $dark\n\n        &.is-active\n          +active\n\n        & + li.nav-section-link\n          margin-top: 0.4rem\n\n    & + &\n      margin-top: 1rem\n\n.docs-menu--desktop\n  display: flex\n\n.docs-menu--mobile\n  display: none\n\n.scrolled\n    background: #1d1c29 !important\n    transition: background 1000ms\n\n.navbar-link, .navbar-item\n\tcolor: white;\n\n.navbar-link, .navbar-end .navbar-item\n\t&:hover\n\t\tcolor:#00aeff\n\n.navbar-dropdown .navbar-item\n\tcolor: #4a4a4a\n\n@media screen and (max-width: 1024px)\n  .is-fixed-top\n    overflow: hidden\n\n  .is-left-padded\n    padding-left: 40px\n\n  .docs-menu--mobile\n    display: flex\n\n  .docs-menu--desktop\n    display: none\n\n@media screen and (max-width: 1023px)\n  .navbar-link, .navbar-item\n    color: $dark\n"
  },
  {
    "path": "assets/sass/style.sass",
    "content": "@charset \"utf-8\"\n\n\n// Site-specific variables here\n$keda-blue: #326de6 \n$keda-light-blue: #679bf0\n$twitter-blue: rgb(29, 161, 242)\n$slack-green: #2EB67D\n$k8s-blue: #326ce5\n\n// Initial Bulma imports\n@import \"bulma/sass/utilities/initial-variables\"\n@import \"bulma/sass/utilities/functions\"\n\n// Bulma-specific overrides\n$primary: $keda-blue\n$secondary: $keda-light-blue\n$footer-color: $white-bis\n$footer-background-color: $black\n$navbar-height: 4rem\n$navbar-burger-color: $primary\n$code: $primary\n$code-background: $white-bis\n$modal-content-width: 50%\n$list-radius: none\n$input-icon-color: $secondary\n$input-icon-active-color: $primary\n$input-color: $black\n\n// Font overrides\n{{ if $fonts := site.Params.fonts }}\n// Sans-serif font\n{{ with (index (where $fonts \".type\" \"sans_serif\") 0).name }}\n$family-sans-serif: \"{{ . }}\", BlinkMacSystemFont, -apple-system, \"Segoe UI\", \"Roboto\", \"Oxygen\", \"Ubuntu\", \"Cantarell\", \"Fira Sans\", \"Droid Sans\", \"Helvetica Neue\", \"Helvetica\", \"Arial\", sans-serif\n{{ end }}\n\n// Monospace font\n{{ with (index (where $fonts \".type\" \"monospace\") 0).name }}\n$family-monospace: \"{{ . }}\", monospace\n{{ end }}\n{{ end }}\n\n// Final Bulma imports\n@import \"bulma/sass/utilities/derived-variables\"\n\n$card-border: 1.5px solid $grey-lighter\n\n$colors: mergeColorMaps((\"secondary\": ($secondary, $white-bis), \"slack-green\": ($slack-green, $white), \"twitter-blue\": ($twitter-blue, $white), \"orange\": ($orange, $white)), $colors)\n\n$card-shadow: none\n$card-color: $black\n//$card-content-padding: 1.5rem 2rem\n//$card-header-padding: 1rem $card-content-padding\n$card-shadow: none\n$card-header-weight: $weight-bold\n$card-header-shadow:  0 0.125em 0.125em rgba($scheme-invert, 0.1)\n$card-footer-border-top: $card-border\n$message-header-color: $dark !important\n$message-body-color: $dark !important\n$message-header-padding: 1em 1.25em\n$message-body-padding: $message-header-padding\n$hero-body-padding: 4rem 1.5rem\n\n// Bulma core\n@import \"bulma/sass/utilities/_all\"\n@import \"bulma/sass/base/_all\"\n@import \"bulma/sass/elements/container\"\n@import \"bulma/sass/grid/columns\"\n@import \"bulma/sass/grid/tiles\"\n@import \"bulma/sass/layout/hero\"\n@import \"bulma/sass/layout/section\"\n@import \"bulma/sass/layout/footer\"\n\n// Elements\n\n// @import \"bulma/sass/elements/box\"\n@import \"bulma/sass/elements/button\"\n@import \"bulma/sass/elements/content\"\n@import \"bulma/sass/elements/icon\"\n// @import \"bulma/sass/elements/image\"\n// @import \"bulma/sass/elements/notification\"\n// @import \"bulma/sass/elements/progress\"\n// @import \"bulma/sass/elements/table\"\n@import \"bulma/sass/elements/tag\"\n@import \"bulma/sass/elements/title\"\n// @import \"bulma/sass/elements/other\"\n\n// Forms\n@import \"bulma/sass/form/shared\"\n@import \"bulma/sass/form/input-textarea\"\n// @import \"bulma/sass/form/checkbox-radio\"\n// @import \"bulma/sass/form/select\"\n// @import \"bulma/sass/form/file\"\n@import \"bulma/sass/form/tools\"\n\n// Components\n// @import \"bulma/sass/components/breadcrumb\"\n@import \"bulma/sass/components/card\"\n@import \"bulma/sass/components/dropdown\"\n@import \"bulma/sass/components/level\"\n@import \"bulma/sass/components/list\"\n@import \"bulma/sass/components/media\"\n@import \"bulma/sass/components/menu\"\n@import \"bulma/sass/components/message\"\n@import \"bulma/sass/components/modal\"\n@import \"bulma/sass/components/navbar\"\n@import \"bulma/sass/components/pagination\"\n// @import \"bulma/sass/components/panel\"\n// @import \"bulma/sass/components/tabs\"\n\n// Custom CSS\n@import \"card\"\n@import \"content\"\n@import \"nav\"\n\n*, *::before, *::after \n  max-width: 100vw\n\n.has-extra-top-margin\n  margin-top: 1.5rem\n\n.has-extra-sm-right-margin\n  margin-right: 0.5rem\n\n.list-item\n  padding: 1rem 1.5rem\n\n  .content\n    margin-top: 0.5rem\n  \n.title, .subtitle\n  &.has-shadow\n    text-shadow: 0 0 10px #000\n\n.card\n  &.is-borderless\n    border: none\n\n  &.has-extra-bottom-margin\n    margin-bottom: 2rem\n\n.has-mouse-icon\n  &:hover\n    cursor: pointer\n\n.is-sticky\n  position: sticky\n  position: -webkit-sticky\n  top: $navbar-height + 2.5rem\n\n.is-page\n  display: flex\n  flex-direction: column\n  min-height: 100vh\n\n  .is-main\n    flex: 1\n    overflow: hidden\n\n=logo($desk, $tab, $touch)\n  +desktop\n    width: $desk\n  +tablet-only\n    width: $tab\n  +mobile\n    width: $touch\n\n.is-cncf-logo\n  +logo(40%, 20%, 70%)\n\n.is-hero-logo\n  +logo(75%, 80%, 50%)\n\n.is-footer-logo\n  +logo(40%, 60%, 40%)\n\n.is-org-logo\n  width: auto\n  max-height: 8rem\n\n.is-bold-letter\n  color: $secondary\n  border-bottom: 4px solid $primary\n\n.title\n  .icon\n    margin-left: 0.75rem\n\n.has-background-pattern\n\tbackground-color: transparent \n\tbackground-image: url(\"data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='100%25' height='100%25' viewBox='0 0 1600 800'%3E%3Cg stroke='%23000' stroke-width='66.7' stroke-opacity='0.05' %3E%3Ccircle fill='%2324CEFF' cx='0' cy='0' r='1800'/%3E%3Ccircle fill='%232fc2f4' cx='0' cy='0' r='1700'/%3E%3Ccircle fill='%2337b6e8' cx='0' cy='0' r='1600'/%3E%3Ccircle fill='%233daadc' cx='0' cy='0' r='1500'/%3E%3Ccircle fill='%23419ecf' cx='0' cy='0' r='1400'/%3E%3Ccircle fill='%234492c2' cx='0' cy='0' r='1300'/%3E%3Ccircle fill='%234587b5' cx='0' cy='0' r='1200'/%3E%3Ccircle fill='%23467ca8' cx='0' cy='0' r='1100'/%3E%3Ccircle fill='%2345719b' cx='0' cy='0' r='1000'/%3E%3Ccircle fill='%2344668e' cx='0' cy='0' r='900'/%3E%3Ccircle fill='%23425c81' cx='0' cy='0' r='800'/%3E%3Ccircle fill='%233f5274' cx='0' cy='0' r='700'/%3E%3Ccircle fill='%233b4867' cx='0' cy='0' r='600'/%3E%3Ccircle fill='%23363f5a' cx='0' cy='0' r='500'/%3E%3Ccircle fill='%2331364e' cx='0' cy='0' r='400'/%3E%3Ccircle fill='%232c2d42' cx='0' cy='0' r='300'/%3E%3Ccircle fill='%23252536' cx='0' cy='0' r='200'/%3E%3Ccircle fill='%231F1D2B' cx='0' cy='0' r='100'/%3E%3C/g%3E%3C/svg%3E\") \n\tbackground-attachment: fixed \n\tbackground-size: cover \n\n.has-extra-padding\n  margin: 1.5rem 0\n\n\n.is-youtube-embed\n  width: 100%\n  height: 20rem\n\n.pagination\n  &.has-bottom-margin\n    margin-bottom: 4rem\n\n.footer\n  .buttons\n    +touch\n      margin-top: 1rem\n\n  a\n    color: $secondary\n\n    &:hover\n      color: #00aeff\n\t\n#cncf\n\t&:hover \n\t\tcolor: #00aeff\n\nhr\n  &.is-thick\n    margin: 3rem 0\n\n.subtitle\n  a\n    color: $secondary !important\n\n    &:hover\n      color: $keda-blue !important\n\n.navbar-item\n  .icon\n    margin-left: 0.1rem\n\n.buttons\n  &.are-spaced\n    .button:not(:first-child)\n      margin-left: 0.5rem\n\t\n.has-no-shadow \n\tbox-shadow: none !important\n\n.is-info-light\n\tbackground: hsl(206, 70%, 96%)\n\n.badge\n  border: 1px solid #dbdbdb\n  border-radius: 20px\n  padding: 3px 6px\n  color: blue\n  font-size: 1rem\n\n.copyBtn \n  padding: 10px\n  background: none\n  height: 50%\n  margin-right: 10px\n  margin-top: 5px\n  color: #ffffff\n  font-size: 18px\n  border: none\n  outline: none\n  border-radius: 10px\n  cursor: pointer\n  &:focus\n      outline: 2px solid #5784f5\n  &:hover\n      outline: 2px solid #5784f5\n  &:active\n      background: #809ce2\n  &:before\n      content: \"Copied\"\n      position: absolute\n      top: -45px\n      right: 0px\n      background: #5c81dc\n      padding: 8px 10px\n      border-radius: 20px\n      font-size: 15px\n      display: none\n  &:after\n      content: \"\"\n      position: absolute\n      top: -20px\n      right: 25px\n      width: 10px\n      height: 10px\n      background: #5c81dc\n      transform: rotate(45deg)\n      display: none\n\n.copy-text-active .copyBtn:before, .copy-text-active .copyBtn:after,\n  display: block\n\n@media screen and (max-width: 1024px)\n  .section\n    width: 100vw\n\t\n.underline--magical\n  background-image: linear-gradient(to right, rgb(250, 112, 154) 0%, rgb(254, 225, 64) 100%)\n  background-repeat: no-repeat\n  background-size: 100% 0.2em\n  background-position: 0 88%\n  transition: background-size 0.25s ease-in-out\n  &:hover\n    background-size: 100% 88%\n\n.underline--magical-1\n  background-image: linear-gradient(to right, #B2FEFA 0%, #0ED2F7 100%)\n  background-repeat: no-repeat\n  background-size: 100% 0.2em\n  background-position: 0 88%\n  transition: background-size 0.25s ease-in-out\n  &:hover\n    background-size: 100% 88%\n\n.underline--magical-2\n  background-image: linear-gradient(to right, #E29587 0%, #D66D75 100%)\n  background-repeat: no-repeat\n  background-size: 100% 0.2em\n  background-position: 0 88%\n  transition: background-size 0.25s ease-in-out\n  &:hover\n    background-size: 100% 88%\n\n.underline--magical-3\n  background-image: linear-gradient(to right, #A7BFE8 0%, #6190E8 100%)\n  background-repeat: no-repeat\n  background-size: 100% 0.2em\n  background-position: 0 88%\n  transition: background-size 0.25s ease-in-out\n  &:hover\n    background-size: 100% 88%\n\n.underline--magical-4\n  background-image: linear-gradient(to right, #F8FFAE 0%, #43C6AC 100%)\n  background-repeat: no-repeat\n  background-size: 100% 0.2em\n  background-position: 0 88%\n  transition: background-size 0.25s ease-in-out\n  &:hover\n    background-size: 100% 88%\n\n.underline--magical-5\n  background-image: linear-gradient(to right, #FDB99B 0%, #CF8BF3 100%)\n  background-repeat: no-repeat\n  background-size: 100% 0.2em\n  background-position: 0 88%\n  transition: background-size 0.25s ease-in-out\n  &:hover\n    background-size: 100% 88%\n \n@media screen and (min-width: 769px)\n  .md-height-desktop\n      height: 9rem\n\n  .filter-icon\n    display: none\n\n  .filter-options\n    display: inline-block\n\n  .filter-pane\n    padding-left: 0\n    padding-top: 20px\n\n@media screen and (max-width: 769px)\n  .filter-icon\n      padding: 0.5rem\n      cursor: pointer\n      border: 1px solid #DBDBDB\n      font-size: 18px\n      border-radius: 0.4rem\n      display: inline-block\n      &:hover\n        border: 1px solid #000000\n\n  .filter-options\n    display: none\n\n  .filter-pane\n    padding-left: 20px\n    padding-top: 10px\n"
  },
  {
    "path": "content/blog/2020-03-31-keda-cncf-sandbox.md",
    "content": "+++\ntitle = \"Kubernetes Event-driven Autoscaling (KEDA) is now an official CNCF Sandbox project 🎉\"\ndate = 2020-03-31\nauthor = \"KEDA Maintainers\"\naliases = [\n    \"/blog/keda-cncf-sandbox/\"\n]\n+++\n\nOver the past year, We've been contributing to Kubernetes Event-Driven Autoscaling (KEDA), which makes application autoscaling on Kubernetes dead simple. If you have missed it, read about it in our [\"Exploring Kubernetes-based event-driven autoscaling (KEDA)\"](https://blog.tomkerkhove.be/2019/06/11/a-closer-look-at-kubernetes-based-event-driven-autoscaling-keda/) blog post.\n\nWe started the KEDA project to address an essential missing feature in the Kubernetes autoscaling story. Namely, the ability to autoscale on arbitrary metrics. Before KEDA, users were only able to autoscale based on metrics such as memory and CPU usage. While these values are essential for autoscaling, they disregard a rich world of external metrics from sources such as Azure, AWS, GCP, Redis, and Kafka (among many more).\n\nTo address this need, KEDA provides a simple, unified API to autoscale deployments without  an in-depth knowledge of Kubernetes internals. With KEDA, users can now treat their Kubernetes deployments like FaaS or PaaS applications with ease!\n\nIn the incredible year since we announced KEDA publicly, adoption has been increasing, and every week we find more passionate and excited members in our weekly community standups. Members of the Kubernetes community have been incredibly accepting. They have been providing feedback, contributing features, and offering great suggestions for the future of our project.\n\nOn November 19, 2019, we released [Kubernetes Event-Driven Autoscaling (KEDA) v1.0](https://cloudblogs.microsoft.com/opensource/2019/11/19/keda-1-0-release-kubernetes-based-event-driven-autoscaling/). This release introduced a ton of features including support for multiple workloads (deployments & jobs), simplified deployment with Helm, documentation on [keda.sh](https://keda.sh/), and (my personal favorite) enterprise-class security with TriggerAuthentication CRD (which allows you to use pod identities such as Azure Managed Identity for pods).\n\nOver time our community has grown - More and more companies such as IBM, Pivotal, VMware, [Astronomer](https://www.astronomer.io/),  and more started contributing to KEDA, we are collaborating with [Knative project](https://knative.dev/) to provide seamless integration with each other and our user base started growing with companies such as, [Purefacts](https://www.purefacts.com/), [SwissRe](https://www.swissre.com/) and more!\n\nWe want to give KEDA more room to grow independently and ensure it has a vendor-agnostic focus. That's why on Jan 14, 2020, we proposed KEDA to  the CNCF as a new Sandbox project.\n\n**Today, we are happy to announce that KEDA is now an [official CNCF Sandbox project](https://www.cncf.io/sandbox-projects/)!** By contributing KEDA to the CNCF we hope to ensure the adoption of KEDA continues to increase and hope to see more companies contribute scalers, integrate it in their products and give it a neutral home. This is a major step and I'm sure the best is yet to come.\n\nWe would love to explicitly thank Liz Rice, Michelle Noorali & Xiang Lifor being our CNCF TOC sponsors and supporting KEDA as well as SIG-Runtime, especially Ricardo Aravena, for recommending us to TOC!\n\nSo... what's next?\n\nIn the near-term, we plan to focus on two major topics:  Autoscaling HTTP workloads and scalers!\n\nCurrently, we do not support HTTP-based autoscaling out-of-the-box, so we hope to create on a Service Mesh Interface (SMI) scaler for autoscaling service mesh workloads!\n\nIn parallel, we have started plans for implementing add-on scalers. What are add-on scalers? We’re glad you've asked! Add-on scalers make it easy for users to define custom [external scalers](https://keda.sh/scalers/external/) without needing to contribute code to KEDA directly. One example of an external scaler is the [Azure Durable Function scaler](https://github.com/kedacore/keda-scaler-durable-functions).\n\nAs this project evolves, our main focus will be to provide guidelines around when to add a scaler to the core and when  to offer it as an external add-on. Next to that, we can create a centralized hub for all add-on scalers to improve discoverability similar to what [Helm Hub](https://hub.helm.sh/) provides.\n\nWe have a lot of ideas and plans but we mainly are interested in what you want! Are you missing scalers, features or capabilities? Let us know!\n\nThanks for reading, and happy scaling!\n\nKEDA Maintainers.\n"
  },
  {
    "path": "content/blog/2020-09-11-keda-2.0-beta.md",
    "content": "+++\ntitle = \"Give KEDA 2.0 (Beta) a test drive\"\ndate = 2020-09-11\nauthor = \"KEDA Maintainers\"\naliases = [\n    \"/blog/keda-2.0-beta/\"\n]\n+++\n\nToday, we are happy to share that our first **beta version of KEDA 2.0 is available**! 🎊\n\n# Highlights\n\nWith this release, we are shipping majority of our planned features.\n\nHere are some highlights:\n\n- **Making scaling more powerful**\n    - Introduction of `ScaledJob` ([docs](https://keda.sh/docs/2.0/concepts/scaling-jobs/))\n    - Introduction of  Azure Log Analytics scaler ([docs](https://keda.sh/docs/2.0/scalers/azure-log-analytics/))\n    - Support for scaling Deployments, Stateful Sets and/or any Custom Resources ([docs](https://keda.sh/docs/2.0/concepts/scaling-deployments/))\n    - Support for scaling on standard resource metrics (CPU/Memory)\n    - Support for multiple triggers in a single `ScaledObject` ([docs](https://keda.sh/docs/2.0/concepts/scaling-deployments/))\n    - Support for scaling to original replica count after deleting `ScaledObject` ([docs](https://keda.sh/docs/2.0/concepts/scaling-deployments/))\n    - Support for controlling scaling behavior of underlying HPA\n- **Easier to operate KEDA**\n    - Introduction of readiness and liveness probes\n    - Introduction of Prometheus metrics for Metrics Server ([docs](https://keda.sh/docs/2.0/operate/))\n    - Provide more information when querying KEDA resources with `kubectl`\n- **Extensibility**\n    - Introduction of External Push scaler ([docs](https://keda.sh/docs/2.0/scalers/external-push/))\n    - Introduction of Metric API scaler ([docs](https://keda.sh/docs/2.0/scalers/metrics-api/))\n    - Provide KEDA client-go library\n\nFor a full list of changes, we highly recommend going through [our changelog](https://github.com/kedacore/keda/blob/v2/CHANGELOG.md#v200)! With our stable release, we'll provide a full overview of what's released in a new blog post.\n\n# Getting started\n\nGet started now, and install our beta with Helm:\n\n>`$ helm repo add kedacore https://kedacore.github.io/charts`\n\n>`$ kubectl create namespace keda`\n\n>`$ helm install keda kedacore/keda --namespace keda --version 2.0.0-beta1.2`\n\nAs an alternative, you can use our deployment YAML:\n\n>`$ kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0-beta/keda-2.0.0-beta.yaml`\n\n# Migrating to KEDA 2.0\n\nWe want it to be super simple to use 2.0 as an existing customer! But what has changed?\n\n- API namespace for KEDA Custom Resources Definitions (CRD) has changed from `keda.k8s.io` to `keda.sh`\n- Scaling jobs is now done through `ScaledJob` CRD, instead of `ScaledObject` CRD\n- `ScaledObject` is now using `spec.scaleTargetRef.name`, instead of `spec.scaleTargetRef.deploymentName`\n- `ScaledObject` no longer requires `deploymentName` label _(last couple of v1 releases were already ignoring it)_\n\nLearn more on how to migrate by using our [migration guide](https://keda.sh/docs/2.0/migration/)!\n\nWith our official release we will provide [migration scripts](https://github.com/kedacore/keda/issues/946) allowing you to migrate your KEDA resources automatically.\n\n> **⚠ Running KEDA 1.x & 2.0 Beta side-by-side is not supported.**\n> \n> KEDA comes with a metrics server and Kubernetes only allows you to run one of them in a cluster.\n> \n>*Learn more about how KEDA is architected in [our docs](https://keda.sh/docs/concepts/#keda-architecture).*\n\n# Conclusion\n\nWe are looking forward to hearing your feedback:\n\n- What do you like and/or what could be improved?\n- What issues did you find?\n- How can the migration be smoother?\n\nWhile we are eagerly waiting for feedback, we plan to release KEDA 2.0 stable around early September, 2020!\n\nThanks for reading, and happy scaling!\n\nKEDA Maintainers.\n"
  },
  {
    "path": "content/blog/2020-11-04-keda-2.0-release.md",
    "content": "+++\ntitle = \"Announcing KEDA 2.0 - Taking app autoscaling to the next level\"\ndate = 2020-11-04\nauthor = \"KEDA Maintainers\"\naliases = [\n    \"/blog/keda-2.0-release/\"\n]\n+++\n\nA year ago, we were excited to **announce our 1.0 release with a core set of scalers**, allowing the community to start autoscaling Kubernetes deployments.  We were thrilled with the response and encouraged to see many users leveraging KEDA for event driven and serverless scale within any Kubernetes cluster.\n\nWith KEDA, any container can scale to zero and burst scale based directly on event source metrics.\n\n![Logo](/img/logos/keda-horizontal-color.png)\n\nWhile KEDA was initially started by Microsoft & Red Hat **we have always strived to be an open & vendor-neutral project** in order to support everybody who wants to scale applications.\n\nThat's why earlier this year we donated and were accepted as a CNCF Sandbox project. We feel this is a strong signal to the community to fully align with the CNCF open mindset and vendor neutrality.\n\n**Since KEDA 1.0 was released we’ve been growing** with new scalers for many different sources including IBM MQ, Postgres, and Huawei Cloudeye, supporting new authentication providers such as HashiCorp Vault, and constantly improving the user experience to make application auto scaling dead-simple.\n\nToday, we are happy to announce another milestone - **KEDA 2.0 is now generally available and ready to scale all your workloads!** 🎊\n\n## Getting started\n\nThere are many ways to get started with KEDA:\n\n- Install with [OperatorHub.io](https://operatorhub.io/operator/keda)\n\n- Install with Helm:\n\n>$ helm repo add kedacore https://kedacore.github.io/charts\n>\n>$ kubectl create namespace keda\n>\n>$ helm install keda kedacore/keda --namespace keda --version 2.0.0\n\n- Install with deployment YAML:\n\n> $ kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml\n\nWant to see it in action? Try one of [our samples](https://github.com/kedacore/samples#keda-20).\n\n## What’s new? 🚀\n\nKEDA 2.0 brings a ton of improvements and fixes. Please check the [changelog](https://github.com/kedacore/keda/blob/main/CHANGELOG.md#v200) to see the full list of changes and improvements in this release.\n\nThere are two types of workloads that can be autoscaled in Kubernetes cluster: a deployment-like workload or job-like workload. KEDA 1.x supported scaling of both types by specifying it in the ScaledObject resource, and was limited to only scaling Kubernetes `Deployment` or `Jobs` resources.\n\nWith KEDA 2.0 we have split both options and introduce a separate resource to describe both types, to better accommodate different needs for the configuration and behavior - **ScaledObject and ScaledJob resources**.\n\nKEDA 2.0 brings another long awaited feature, **you can specify multiple triggers on one ScaledObject/ScaledJob**, this way your workload can be autoscaled based on different triggers (eg. Kafka and Prometheus), KEDA will select the maximum value from the scalers to define the scaling decision, ie. the target number of replicas.\n\n### ScaledObject improvements\n\nScaledObject describes the specification for deployment-like workloads. And we are not talking just about `Kubernetes Deployments`, with **KEDA 2.0 you can scale `StatefulSets` or any other `CustomResource` that implements `/scale` subresource (eg. Argo Rollouts)**. This brings more scenarios and use cases that could benefit from KEDA and its autoscaling capabilities. Users can simply implement /scale endpoint on their Custom Resources and get autoscaling working out of the box!\n\nIf you are running KEDA on Kubernetes version >= 1.18, you can benefit from configurable scaling behavior, which allows you to **specify the behavior for scaling up and down**. This exposes these new capabilities of the Kubernetes Horizontal Pod Autoscaler to KEDA.\n\n### Introducing ScaledJob\n\nAs mentioned earlier, KEDA 2.0 brings a separate custom resource for scaling of `Kubernetes Jobs`. This allows us to accommodate and simplify the specification and configuration, as scaling `Jobs` has different needs than scaling deployment-like workloads.\n\nScaling Jobs can have different use cases and those could be even different with different scalers. That’s why ScalingStrategy for ScaledJobs was introduced in KEDA 2.0, which allows users to **select different strategies for scaling of Kubernetes Jobs**.\n\n### New scalers\n\nKEDA 2.0 introduces **new scalers** for you to use.\n\nFor starters, our community worked together to add **Azure Log Analytics & IBM MQ scalers**.\n\nBy using our new CPU / Memory scaler you no longer have to mix & match Horizontal Pod Autoscalers (HPA) & ScaledObjects anymore - You can now **fully standardize on KEDA and we’ll handle all the HPAs for you!**\n\nWith our new **external push scaler**, you can build your own scaler and **trigger scaling actions in KEDA by using a push-model for more reactive autoscaling**, instead of a pull-model with our current pull-based model in our external scaler.\n\nFinally, with our new **Metrics API scaler you can automatically scale on metrics provided through a REST API** without having to build your own scaler. This allows you to make autoscaling decisions based on a metric source that is available in your landscape (for example an in-house API or Microsoft Dynamics CRM API to automate processes).\n\nOn top of these new scalers, we’ve made a variety of improvements to the current scalers to optimize our scaling.\n\n### Operations & Extensibility\n\nKEDA now exposes **Liveness and Readiness probes** on both Operator and Metrics server pods, so administrators have a better overview of the state and health of KEDA.\n\nKEDA Metrics Server now **exposes Prometheus metrics about each used scaler**. Currently these metrics work with ScaledObject metrics when the HorizontalPodAutoscaler is active (> 0 replicas). In further releases of KEDA there are plans to extend this capability and serve metrics for ScaledJobs as well.\n\nDevelopers can now use a **go-client library** that is [exposed](https://github.com/kedacore/keda/tree/main/pkg/generated) to allow easy manipulation of the KEDA API from within applications.\n\n## Migrating to KEDA 2.0\n\nWe want it to be super simple to use 2.0 as an existing customer! But what has changed?\n\nWe’re making some general changes:\n\n- API namespace for KEDA Custom Resources Definitions (CRD) has changed from `keda.k8s.io` to `keda.sh`\n- Scaling jobs is now done through `ScaledJob` CRD, instead of `ScaledObject` CRD\n- `ScaledObject` is now using `spec.scaleTargetRef.name`, instead of `spec.scaleTargetRef.deploymentName`\n- `ScaledObject` no longer requires `deploymentName` label _(last couple of v1 releases were already ignoring it)_\n\nIn order to provide a more consistent experience across all scalers, we’re introducing improved flexibility & usability of trigger metadata for which we had to do some [cross-scaler breaking changes](https://keda.sh/docs/2.0/migration/#improved-flexibility--usability-of-trigger-metadata) as well as improvements for [Azure Service Bus, Kafka & RabbitMQ scalers](https://keda.sh/docs/2.0/migration/#scalers).\n\nLearn more about how to migrate by using our [migration guide](https://keda.sh/docs/2.0/migration/)!\n\n> **⚠ Running KEDA 1.x & 2.0 side-by-side is not supported.**\n>\n> KEDA comes with a metrics server and Kubernetes only allows you to run one of them in a cluster.\n>\n>*Learn more about how KEDA is architected in [our docs](https://keda.sh/docs/concepts/#keda-architecture).*\n\n## KEDA 💘 Community\n\n**KEDA would not have been what it is today without our great community** - They have helped us shape our KEDA 2.0 release with their feature request, contributions, testing our release candidates and their support!\n\nIt is wonderful to see how **more and more people from [across the globe](https://keda.devstats.cncf.io/d/50/countries-statistics-in-repository-groups?orgId=1&var-period_name=Quarter&var-countries=All&var-repogroup_name=All&var-metric=contributions&var-cum=countries) start to contribute back** from companies such as IBM, Oracle, Pivotal, Polidea, Tripadvisor, VMWare, Zapier and [so many more](https://keda.devstats.cncf.io/d/4/company-statistics-by-repository-group?orgId=1&var-period=m&var-metric=activity&var-repogroup_name=All&var-companies=All) - We could not have done this without them!\n\nWe’re honored to see other technologies adopting KEDA to use in their own products, here are a few of them:\n\n- **Apache Airflow & Astronomer** are using KEDA to autoscale workflows. ([blog post](https://www.astronomer.io/blog/the-keda-autoscaler/))\n- **Dapr** is recommending KEDA to autoscale Dapr apps ([walkthrough](https://docs.dapr.io/developing-applications/integrations/autoscale-keda/) & [sample](https://github.com/dapr/samples/blob/master/functions-and-keda/README.md))\n- **Fission** is building a catalog of KEDA connectors to scale their serverless functions on Kubernetes ([GitHub](https://github.com/fission/keda-connectors))\n- **Knative** is using KEDA to autoscale Knative Event Sources ([GitHub](https://github.com/knative-sandbox/eventing-autoscaler-keda))\n\nWe are super thankful that these companies and technologies have adopted KEDA:\n\n{{< user-icons >}}\n\nAnother user of KEDA is Alibaba Cloud who has adopted KEDA for all their autoscaling:\n\n> “Alibaba's [Enterprise Distributed Application Service (EDAS)](https://www.alibabacloud.com/product/edas) which is built with [KubeVela](https://github.com/oam-dev/kubevela/) project adopts KEDA as the implementation for its auto-scaling trait (see: [trait system of Open Application Model](https://github.com/oam-dev/spec/blob/master/6.traits.md)) from mid of 2020. In Alibaba, EDAS has served more than 1000+ applications from both Alibaba Cloud's customers and internal scenarios. EDAS's KEDA based auto-scaling trait uses Alibaba's ARMS (i.e. Application Real-Time Monitoring Service) as the trigger by default, and it's also under integration with AIOps system of EDAS for advanced scenarios such as capacity diagnose based auto-scaling.”\n>\n> -- *Yan Xun, Senior Engineer of Alibaba Cloud*\n\nAre you using KEDA in production as well? Don’t hesitate and [let us know](https://github.com/kedacore/keda#become-a-listed-keda-user)!\n\n## Looking ahead 🧭\n\nWe’ve been working on this milestone for a while and are happy to finally be able to officially release KEDA 2.0! But we’re not stopping there and have already started working on v2.1.\n\nTransparency is essential to become a successful open-source project and we want to be open on the future of KEDA. Because of that, we’re introducing a **public high-level roadmap of KEDA** ([link](https://github.com/kedacore/keda/projects/3)) allowing you to get an idea of where we are going with the project and allow you to provide suggestions so we can adapt.\n\nNext, we are going to **further improve KEDA as a project and focus on making it more robust** by introducing a security policy, automated vulnerability scanning, and such to ensure we are shipping secure software so that you don’t have to worry about it.\n\nAs KEDA continues to grow, many organizations have contributed back and shared a number of very interesting use cases that rely on KEDA. We are working on writing a reference case to show the value of KEDA for customers.\n\nAs we continue to work with the community, our goal is to **propose to graduate to CNCF Incubation** ([issue](https://github.com/kedacore/keda/issues/1143)) **later this year / early next year**. Any support we can get from the community will be extremely helpful as we move to make the next steps in bringing the benefits of KEDA to every user.\n\nLast but not least, we want people to be able to show their support for KEDA and are working on **providing merchandise** that you can purchase which you can wear with pride! Sit back and wait for our swag to show up.\n\nThanks for reading, and happy scaling!\n\nKEDA Maintainers.\n"
  },
  {
    "path": "content/blog/2021-03-26-migrating-to-github-container-registry.md",
    "content": "+++\ntitle = \"Migrating our container images to GitHub Container Registry\"\ndate = 2021-03-26\nauthor = \"KEDA Maintainers\"\naliases = [\n    \"/blog/migrating-to-github-container-registry/\"\n]\n+++\n\nWe provide **various ways to [deploy KEDA](https://keda.sh/docs/latest/deploy/) in your cluster** including by using [Helm chart](https://github.com/kedacore/charts), [Operator Hub](https://operatorhub.io/operator/keda) and raw YAML specifications.\n\nThese deployment options all rely on the container images that we provide which are available on **[Docker Hub](https://hub.docker.com/u/kedacore), the industry standard for public container images**.\n\nHowever, we have found that Docker Hub is no longer the best place for our container images and are migrating to GitHub Container Registry (Preview).\n\n## Why are making this change?\n\n### Docker Hub is introducing rate limiting and image retention\n\nOver the past couple of years, Docker Hub has become the industry standard for hosting public container images. This has become a big burden for Docker to manage all the traffic and decided in 2020 to make some changes:\n\n- Anonymous image pulls are being rate limited\n- Unused images will no longer be retained\n\nBecause we want to ensure that our end-users can use KEDA without any issues, we want to make them available to anyone without any limitations.\n\nLearn more about these changes in [Docker's FAQ](https://www.docker.com/pricing/resource-consumption-updates) and our issue on [GitHub](https://github.com/kedacore/keda/issues/995).\n\n### Gaining insights on KEDA adoption\n\nAs maintainers, **we find it hard to measure the adoption of KEDA** to understand how many end-users are using older versions of KEDA and what the growth is over time.\n\nDocker Hub provides a vague total pull count per container image, but it does not give in-depth details concerning the tags and what the pull growth is over time.\n\nIn GitHub Container Registry, however, **metrics are provided out-of-the-box on a per-tag basis** allowing us to better understand what our customers are using and make better decisions when we no longer support a given version.\n\n### Bringing our artifacts closer to home\n\nLastly, we want to **bring our artifacts closer to our home on GitHub**. By using more of the GitHub ecosystem, we believe that this integration will only improve and get tighter integration with our releases and such.\n\n## What is changing?\n\nOur container images are being published on [GitHub Container Registry](https://github.com/orgs/kedacore/packages?type=source) for end-users to pull them.\n\nBecause of this, the names of our container images are changing:\n\n| Component      | New Image (GitHub Container Registry)     | Legacy Image (Docker Hub)         |\n| :------------- | :---------------------------------------- | --------------------------------- |\n| Metrics Server | `ghcr.io/kedacore/keda-metrics-apiserver` | `kedacore/keda-metrics-apiserver` |\n| Operator       | `ghcr.io/kedacore/keda`                   | `kedacore/keda`                   |\n\n## When is this taking place?\n\nAs of v2.2, we have started publishing our new container images to GitHub Container Registry in parallel to Docker Hub.\n\nThis allows customers to already migrate to our new registry and consume our artifacts there.\n\n**Once GitHub Container Registry becomes generally available (GA), we will no longer publish new versions to Docker Hub.**\n\n## What is the impact for end-users?\n\n**If you are using one of our deployment options, end-users are not be impacted.**\n\nSince v2.2, we are using GitHub Container Registry by default and you are good to go.\n\nIf you are using your own deployment mechanism, then you will have to pull the container images from GitHub Container Registry instead.\n\n## Join the conversation\n\nDo you have questions or remarks? Feel free to join the conversation on [GitHub Discussions](https://github.com/kedacore/keda/discussions/1700).\n\nThanks for reading, and happy scaling!\n\nKEDA Maintainers."
  },
  {
    "path": "content/blog/2021-04-06-why-alibaba-cloud-uses-keda-for-app-autoscaling.md",
    "content": "+++\ntitle = \"Why Alibaba Cloud uses KEDA for application autoscaling\"\ndate = 2021-04-06\nauthor = \"Yan Xun, Andy Shi, and Tom Kerkhove\"\naliases = [\n    \"/blog/why-alibaba-cloud-uses-keda-for-app-autoscaling/\"\n]\n+++\n\n> This blog post was initially posted on [CNCF blog](https://www.cncf.io/blog/2021/03/30/why-alibaba-cloud-uses-keda-for-application-autoscaling/) and is co-authored by Yan Xun, Senior Engineer from Alibaba Cloud EDAS team & Andy Shi, Developer Advocator from Alibaba Cloud.\n\nWhen scaling Kubernetes there are a few areas that come to mind, but if you are new to Kubernetes this can be a bit overwhelming.\n\nIn this blog post; we will briefly explain the areas that need to be considered, how KEDA aims to make application auto-scaling simple, and why Alibaba Cloud’s [Enterprise Distributed Application Service (EDAS)](https://www.alibabacloud.com/product/edas) has fully standardized on KEDA.\n\n## An introduction to scaling Kubernetes\n\nWhen managing Kubernetes clusters & applications, you need to carefully monitor a variety of things such as :\n\n- **Cluster capacity** – Do we have enough resources available to run our workloads?\n- **App Workload** – Does the application have enough resources available? Can it keep up with the pending work (ie. queue depth)\n\nIn order to automate this, you’d typically set up alerts to get notified or even use auto-scaling. Kubernetes is a great platform and helps you with this out-of-the-box.\n\n**Scaling your cluster** can be easily done by using the **Cluster Autoscaler** component that will monitor your cluster for pods that are unable to be scheduled due to resource starvation and start adding/removing nodes accordingly.\n\nSince Cluster Autoscaler only kicks in when your pods are over-scheduled, you may have a time gap during which your workloads are not up and running.\n\n**Virtual Kubelet**, a CNCF sandbox project, is a tremendous help that allows you to add a “virtual node” to your Kubernetes cluster on which pods can be scheduled.\n\n![Virtual Kubelet](/img/blog/alibaba-cloud-ref-case/virtual-kubelet.png)\n\nBy doing this, platform providers (such as Alibaba, Azure, HashiCorp and [others](https://github.com/virtual-kubelet/virtual-kubelet#providers)) allow you to **overflow your pending pods outside of your cluster until it provides the required cluster capacity to mitigate this issue**.\n\nIn addition to scaling the cluster, Kubernetes allows you to easily **scale your application**:\n\n- Horizontal Pod Autoscaler ([HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)) allows you to add/remove more pods to your workloads to scale in/out (adding or removing replicas)\n- Vertical Pod Autoscaler ([VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)) allows you to add/remove resources to your pods to scale up/down (adding or removing CPU or memoru)\nAll of this combined gives you a very good starting point to scale your application.\n\n## The limitations of Horizontal Pod Autoscaler (HPA)\n\nWhile the HPA is a great place to start, it is mainly focused on metrics of the pods themselves allowing you to scale it based on CPU & memory. That said, you can fully configure how it should be autoscaled which makes it powerful.\n\nWhile that is ideal for some workloads, you’d typically want to scale on metrics that are available somewhere else such as Prometheus, Kafka, a cloud provider, or other events.\n\nThanks to the [external metric support](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-external-metrics.md), users can install metric adapters that serve a variety of metrics from external services and make them available to autoscale on by using a metric server.\n\nThere is one caveat, though, you can only run one metric server inside your cluster which means that you’ll have to choose where your custom metrics come from.\n\n![Standard App Autoscaling](/img/blog/alibaba-cloud-ref-case/vanilla-autoscaling.png)\n\nYou could use Prometheus and use tools, such as Promitor, to bring your metrics from other providers and use that as a single-source-of-truth to scale on but that requires a lot of plumbing and work to scale.\n\nThere must be a simpler way… Yes, use Kubernetes Event-Driven Autoscaling (KEDA)!\n\n## What is Kubernetes Event-Driven Autoscaling (KEDA)?\n\nKubernetes Event-Driven Autoscaling (KEDA) is a single-purpose event-driven autoscaler for Kubernetes that can be easily added to your Kubernetes cluster to scale your applications.\n\nIt aims to make application auto-scaling dead-simple and optimize for cost by supporting scale-to-zero.\n\nKEDA takes away all the scaling infrastructure and manages everything for you, allowing you to scale on 30+ systems or extend it with your own scalers.\n\nUsers only need to create a ScaledObject or ScaledJob that defines what you want to scale and what triggers you want to use; KEDA will handle all the rest!\n\n![App Autoscaling with KEDA](/img/blog/alibaba-cloud-ref-case/keda-autoscaling.png)\n\nAnd you can literally scale anything; even if it’s a CRD from another tool you are using, as long as it implements /scale subresource.\n\nSo, does KEDA reinvent the wheel? No! Instead, it extends Kubernetes by using HPAs under the hood that use our external metrics which are served from our own metrics adapter that replaces all the other adapters.\n\n![KEDA Architecture](/img/blog/alibaba-cloud-ref-case/architecture.png)\n\nLast year, KEDA joined the CNCF as CNCF Sandbox project and is planning to propose to graduate to Incubation later this year.\n\n## Introduce Alibaba’s practice based on OAM/KubeVela and KEDA\n\nAs the major enterprise PaaS offering on Alibaba Cloud, [Enterprise Distributed Application Service (EDAS)](https://www.alibabacloud.com/product/edas) has been serving countless developers on the public cloud with massive scale for years. From an architectural perspective, EDAS is built with the [KubeVela project](https://kubevela.io/). Its overall architecture is like the below.\n\n![EDAS Overview](/img/blog/alibaba-cloud-ref-case/edas-overview.png)\n\nIn production, EDAS integrated ARMS monitoring service on Alibaba Cloud to provide monitoring and fine-grained metrics of the application.\n\nEDAS team added an ARMS Scaler to the KEDA project to perform autoscaling. They also added a couple of features and fixed some bugs in the KEDA v1 release. Including:\n\n- When there are multiple Triggers, the values will be summed up rather than leaving them as individual values.\n- When creating KEDA HPA, the length of the name will be limited to 63 characters to avoid triggering DNS complaints.\n- Triggers can not be disabled and this might cause trouble in production.\n\nEDAS team is actively working on sending these fixes to KEDA upstream, though some of them have already been added to the V2 release.\n\n## Why Alibaba Cloud standardized on KEDA as their application autoscaler\n\nWhen it comes to auto-scaling features, EDAS originally used the upstream Kubernetes HPA with the CPU and Memory as the two metrics in the beginning. However, as the user base grows and requirement diversifies, the EDAS team soon found the limitations of the upstream HPA:\n\n1. **Limited support for customized metrics, especially for application-level fine-grained metrics**\nThe upstream HPA focuses on the container level metrics, such as CPU and Memory, which is too coarse for the applications. Metrics that reflect the application loads, such as RT and QPS are not supported out of the box. Yes, HPA can be extended. However, that capability is limited when it comes to application-level metrics. EDAS team was often forced to fork code when trying to introduce fine-grained application-level metrics.\n2. **No support for scale-to-zero**\nMany users have the requirement of Scale to Zero when their microservices are not being consumed. This requirement is not limited just to FaaS/Serverless workloads. It saves costs and resources for all users. Currently, upstream HPA doesn’t support this feature.\n3. **No support for scheduled scaling**\nAnother strong requirement from the EDAS users is the scheduled scaling capability. Again, upstream HPA doesn’t provide this feature, and the EDAS team needs to look for non-vendor lock alternatives.\nBased on those requirements, the EDAS team started planning the new version of EDAS auto-scaling feature. In the meantime, EDAS went through an overhaul of its underlying core components by introducing OAM at the beginning of 2020. OAM gives EDAS the standardized, pluggable application definition to replace its in-house Kubernetes Application CRD. And the extensibility of this model makes it possible for EDAS to integrate with any new capability from the Kubernetes community with ease. In that context, the EDAS team tried to align the need for new auto-scaling features for EDAS with looking for a standard implementation for OAM’s autoscaling trait.\n\nBase on the use cases, the EDAS team summarized three criteria:\n\n1. The auto-scaling feature should present itself as a simple atomic capability without attachment to any complex solutions.\n2. The metrics should be pluggable, so the EDAS team can customize it and build on top of it to support various requirements.\n3. It should support Scale to Zero out of the box.\n\nAfter detailed evaluation, the EDAS team picked the project KEDA, which was open-sourced by Microsoft & Red Hat and has been donated to CNCF. KEDA has several useful Scalers that come by default and supports Scale to Zero out of the box. It provides fine-grained auto scaling for applications. It has the concept of Scalar and Metrics adapter, which enables powerful plugin architecture while providing a unified API layer. Most importantly, the design of KEDA focuses on autoscaling only so it can be integrated as an OAM trait at ease. Overall, KEDA is a good fit for EDAS.\n\n## Looking Ahead\n\nAs the next step, Alibaba is actively working on making KEDA trait driven by AIOps, with the goal to bring intelligent decision making to its autoscaling behavior. This will essentially enable autoscaling decisions based on expert system and historical data analysis with leverage of newly implemented application QoS trigger and database metrics trigger etc in Alibaba’s KEDA components. Thus, we will expect a more powerful, intelligent, and stable KEDA based auto-scaling capability will be shipped in KEDA soon.\n"
  },
  {
    "path": "content/blog/2021-05-27-azure-pipelines-scaler.md",
    "content": "+++\ntitle = \"Autoscaling Azure Pipelines agents with KEDA\"\ndate = 2021-05-27\nauthor = \"Troy Denorme\"\n+++\n\nWith the addition of Azure Piplines support in KEDA, it is now possible to autoscale your Azure Pipelines agents based on the agent pool queue length.\n\nSelf-hosted Azure Pipelines agents are the perfect workload for this scaler. By autoscaling the agents you can create a scalable CI/CD environment.\n\n> 💡 The number of concurrent pipelines you can run is limited by your [parallel jobs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents#parallel-jobs).\n> \n> KEDA will autoscale to the maximum defined in the ScaledObject and does not limit itself to the parallel jobs count defined for the Azure DevOps organization.\n\n## What are Azure Pipelines self-hosted agents?\n\nAzure Pipelines jobs can run on different kinds of agents ([docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/agents)). But if you want full control, you are going to have to use self-hosted agents.\nAgents are able to run on Linux, macOS or Windows machines and can be packaged in to a container.\n\nWhen running self-hosted agents on Kubernetes, there is no out-of-the-box support for autoscaling. However, with KEDA v2.3 you can now autoscale your self-hosted agents on Kubernetes based on the amount of pending jobs in your agent pool.\n\nYou can run the agents as a `Deployment` or a `Job` in Kubernetes and scale them accordingly with a `ScaledObject` or a `ScaledJob`.\n\n## Deploying a self-hosted agent on Kubernetes as a Deployment\n\n### Create the container image\n\nTo create a basic Azure Pipelines agent image you can follow the instructions from [the official docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker#linux).\n\n### Deploy on Kubernetes\n\nYou can easily deploy the agent as a Kubernetes deployment by using this Kubernetes manifest:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azdevops\ndata:\n  AZP_TOKEN: <base64 encoded PAT>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azdevops-deployment\n  labels:\n    app: azdevops-agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: azdevops-agent\n  template:\n    metadata:\n      labels:\n        app: azdevops-agent\n    spec:\n      containers:\n      - name: azdevops-agent\n        image: <azdevops-image>\n        env:\n          - name: AZP_URL\n            value: \"https://dev.azure.com/<organization>\"\n          - name: AZP_POOL\n            value: \"<agent pool name>\"\n          - name: AZP_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: azdevops\n                key: AZP_TOKEN\n        volumeMounts:\n        - mountPath: /var/run/docker.sock\n          name: docker-volume\n      volumes:\n      - name: docker-volume\n        hostPath:\n          path: /var/run/docker.sock\n```\n\n### Autoscaling with KEDA\n\nAfter the deployment is created you need to create the `ScaledObject` in order for KEDA to start scaling the deployment.\n\nTo scale based on the queue length of an Azure Pipelines agent pool, you can use the `azure-pipelines` trigger as of KEDA v2.3.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <base64 encoded PAT>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5 \n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\nThe default `targetPipelinesQueueLength` is `1`, so there will be one agent for each job.\n\n> ⚠ The Azure Pipelines scaler supports scaling to zero but you need at least one agent registered in the agent pool in order for new jobs to be scheduled on the pool.\n\n### Running Azure Pipelines jobs\n\nAfter deploying the agent and the KEDA `ScaledObject` it is time to see the autoscaling in action.\n\nFirst, check the current pods running in the deployment:\n```sh\n$ kubectl get pods\nNAME                                   READY   STATUS    RESTARTS   AGE\nazdevops-deployment-5854bbbf84-r86qv   1/1     Running   0          75s\n```\n\n![deployment agents](/img/blog/azure-pipelines-scaler/deployment-agents.png)\n\nNow let's queue some builds.\n\n![azure devops builds](/img/blog/azure-pipelines-scaler/deployment-builds.png)\n\nAs a result, you see that KEDA starts scaling out the pods to meet the pending jobs:\n\n```sh\n$ kubectl get pods\nNAME                                   READY   STATUS    RESTARTS   AGE\nazdevops-deployment-5854bbbf84-4gfbx   1/1     Running   0          36s\nazdevops-deployment-5854bbbf84-r86qv   1/1     Running   0          12m\nazdevops-deployment-5854bbbf84-tm47k   1/1     Running   0          36s\n```\n\nAnd they appear on Azure Pipelines as well:\n\n![deployment agents](/img/blog/azure-pipelines-scaler/deployment-agents-autoscaled.png)\n\n## Run the self-hosted agent as a Job\n\nWhen running your agents as a deployment you have no control on which pod gets killed when scaling down. ([see KEDA docs](https://keda.sh/docs/1.4/concepts/scaling-deployments/#long-running-executions))\n\nIf you run your agents as a `Job`, KEDA will start a Kubernetes job for each job that is in the agent pool queue. The agents will accept one job when they are started and terminate afterwards.\nSince an agent is always created for every pipeline job, you can achieve fully isolated build environments by using Kubernetes jobs.\n\nThe following manifest is an example of a `ScaledJob` combined with the Azure Pipelines agent.\nYou have to use a modified image for this where the agent terminates itself after running a job. ([docs](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux#run-once))\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: azdevops-scaledjob\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: azdevops-agent-job\n          image: <azdevops-image>\n          imagePullPolicy: Always\n          env:\n          - name: AZP_URL\n            value: \"<organizationUrl>\"\n          - name: AZP_TOKEN\n            value: \"<token>\"\n          - name: AZP_POOL\n            value: \"<agentpool>\"\n          volumeMounts:\n          - mountPath: /var/run/docker.sock\n            name: docker-volume\n        volumes:\n        - name: docker-volume\n          hostPath:\n            path: /var/run/docker.sock\n  pollingInterval: 30\n  successfulJobsHistoryLimit: 5\n  failedJobsHistoryLimit: 5\n  maxReplicaCount: 10   \n  scalingStrategy:\n    strategy: \"default\"               \n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n```\n\n### Placeholder agent\n\nYou cannot queue an Azure Pipelines job on an empty agent pool because Azure Pipelines cannot validate if the pool matches the requirements for the job.\n\nWhen you try to do this you will encounter the following error:\n\n> ##[error]No agent found in pool keda-demo which satisfies the specified demands: Agent.Version -gtVersion 2.163.1\n\nYou can, however, use a workaround to register an agent as a placeholder which allows you to queue jobs on an agent pool that has no agents that are online.\n\n\nMake sure you don't execute any cleanup code in your container to unregister the agent when removing it to keep the placeholder agent registered in the agent pool.\n\n### Seeing `ScaledJobs` in action\n\nTo allow scaling to zero and create agents on-demand, a template agent was created as a placeholder to be able to queue jobs.\n\n![placeholder agent](/img/blog/azure-pipelines-scaler/placeholder-agent.png)\n\nNow, let's queue some pipelines:\n\n![azure devops builds](/img/blog/azure-pipelines-scaler/jobs-builds.png)\n\nKEDA will create a Kubernetes job for each pending job in the queue for the specified agent pool.\n\n```sh\n$ kubectl get pods\nNAME                             READY   STATUS    RESTARTS   AGE\nazdevops-scaledjob-2hshf-mp5jl   1/1     Running   0          24s\nazdevops-scaledjob-5gzr5-p8625   1/1     Running   0          24s\nazdevops-scaledjob-mmlzc-rw5gm   1/1     Running   0          24s\n```\n\nOnce that happens, you will see the agents are starting to process the pending Azure Pipelines jobs:\n\nOnce that happens, you will see the jobs in the Azure Pipelines' agent pool:\n\n![scaledjobs agents](/img/blog/azure-pipelines-scaler/jobs-agents-autoscaled.png)\n\nUsing a `ScaledJob` is the preferred way to autoscale your Azure Pipelines agents if you have long-running jobs.\nThe other option is using a `deployment` and leveraging the container lifecycle. ([docs](https://keda.sh/docs/1.4/concepts/scaling-deployments/#leverage-the-container-lifecycle))\n"
  },
  {
    "path": "content/blog/2021-06-24-announcing-http-add-on.md",
    "content": "+++\ntitle = \"Announcing KEDA HTTP Add-on v0.1.0\"\ndate = 2021-06-24\nauthor = \"Aaron Schlesinger and Tom Kerkhove\"\n+++\n\nOver the past few months, we’ve been adding more and more scalers to KEDA making it easier for users to scale on what they need. Today, we leverage more than 30 scalers out-of-the-box, supporting all major cloud providers & industry-standard tools such as Prometheus that can scale any Kubernetes resource.\n\nBut, we are missing a major feature that many modern, distributed applications need - the ability to scale based on HTTP traffic.\n\nIt’s time to change this.\n\n>Note: You can build your own custom HTTP autoscaling system using the [Prometheus scaler](https://keda.sh/docs/2.2/scalers/prometheus/) per our FAQ. The new HTTP Addon adds first-class, end-to-end support for HTTP.\n\n## Introducing our HTTP add-on for KEDA\n\nAutoscaling HTTP is often not as straightforward as other event sources. You don't know how much traffic will be coming and, given its synchronous nature, supporting scale-to-zero HTTP applications requires an intelligent intermediate routing layer to “hold” the incoming request(s) until new instances of the backend application are created and running.\n\nWe’re happy to announce our experimental HTTP add-on for KEDA which is purely focused on solving this problem. This new project introduces an `HTTPScaledObject` CRD, which you use to autoscale a Kubernetes `Deployment`, including scale-to-zero.\n\nWe’ve taken a “batteries included with reasonable defaults” approach to designing and building the HTTP add-on. This means that you don’t have to run other tools such as Prometheus. At the same time, the system is made up of well-defined, reusable components that can run independently. You can opt-out of the defaults and customize components as you see fit. In many cases, you can even run most of the components independently.\n\nScaling based on incoming HTTP traffic is different from core KEDA triggers for two reasons:\n\n- There is no standard existing API you can call to get a counter or other metric to scale on. For example, we cannot call the Kafka API to get the length of a queue.\n- You need to set up the infrastructure to route HTTP requests to the server you’re autoscaling\n\nYou can see the HTTP add-on as just another trigger in your scaling toolbox.\n\n⚠ Given its experimental state of this project, breaking changes can occur and the HTTP add-on is not supported for production workloads yet.\n\n### How does it work?\n\nSince KEDA already does an excellent job listening for events and autoscaling, the HTTP add-on simply adds an HTTP-aware layer on top.\n\nThe system is made up of 3 components:\n\n- **Interceptor**: This component accepts HTTP requests into the system, reports pending HTTP request queue metrics to the external scaler, and forwards requests to the target application.\n  - If the application is currently scaled to zero replicas, the interceptor will hold requests until it scales up\n- **External scaler**: This is an [external push scaler](https://keda.sh/docs/2.1/scalers/external-push/) that constantly pings the interceptor to get pending HTTP queue metrics. It transforms these data and sends them directly down to KEDA, which then makes a scaling decision\n- **Operator**:  This is an [Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) that runs for the convenience of the user. It listens for new [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) resources, called `HTTPScaledObject`s, and creates and configures interceptors and scalers so that your existing [`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) will begin autoscaling according to incoming HTTP traffic.\n\n![architecture diagram](/img/blog/http-add-on/arch.png)\n\n## Seeing it in action\n\nWe’ve aimed to make the HTTP add-on approximately as simple to operate and use as KEDA. \n\nThere are two major steps to using it:\n\n1. Install the KEDA HTTP add-on operator\n2. Create a new `HTTPScaledObject`\n\n### Installing the Operator\n\nThis is an optional step, but we highly recommend it because the operator makes interacting with the HTTP add-on more convenient. We’ve packaged the operator up in a [Helm](https://helm.sh) chart, which you can install by following the instructions below.\n\n_The commands below have been tested on Mac and Linux (Ubuntu). They likely work on Windows WSL2, but won’t work on Powershell. You’ll also need to ensure you have access to a Kubernetes cluster with a Kubernetes configuration file properly configured._\n\n#### Install KEDA\n\nFirst, make sure you’ve set up an environment variable for the namespace you’d like to install everything into:\n\n```shell\nexport NAMESPACE=mynamespace\n```\n\nNext, install KEDA:\n\n```shell\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install --create-namespace -n ${NAMESPACE} keda kedacore/keda\n```\n\n#### Install the Operator\n\nNow that KEDA is installed, you can install the operator:\n\n```shell\nhelm install --create-namespace -n ${NAMESPACE} http-add-on kedacore/keda-add-ons-http\n```\n\n### Install an `HTTPScaledObject`\n\nThe `HTTPScaledObject` CRD instructs the operator to install and configure the interceptor and scaler for a specified `Deployment`. For this to work, you’ll need to have a Deployment running in the same `$NAMESPACE` and a Service configured to route traffic to the pods in that `Deployment`.\n\n>We've created a sample application [here](https://github.com/kedacore/http-add-on/tree/main/examples/xkcd) as a Helm chart for you. It comes complete with a properly configured `HTTPScaledObject`, so when you install the chart, everything will be automatically configured for you and you can skip the rest of this section. If you install this chart, you can skip the rest of this section.\n\nAfter you have your application set up, copy the following YAML into a file called myautoscaledapp.yaml:\n\n```yaml\nkind: HTTPScaledObject\napiVersion: http.keda.sh/v1alpha1\nmetadata:\n    name: myapp\nspec:\n    scaleTargetRef:\n        deployment: myAppDeployment\n        service: myAppService\n        port: 8080\n```\n\nAnd finally, submit it to your Kubernetes cluster:\n\n```shell\nkubectl create -f -n $NAMESPACE myautoscaledapp.yaml\n```\n\nThe operator will pick up the CRD and, when it’s done installing and configuring, you’ll see a new `Service` (among other things!) that’s ready to route HTTP traffic to your Deployment. Send all of your HTTP to the Service, and the Deployment will begin autoscaling!\n\n### Cleaning up\n\nTo clean up, remove the HTTPScaledObject you created, then delete the two Helm charts you installed:\n\n```shell\nkubectl delete -n $NAMESPACE httpscaledobject myapp\nhelm delete -n ${NAMESPACE} kedahttp\nhelm delete -n ${NAMESPACE} keda\n```\n\n## What's next?\n\nWith this release, we've built a solid foundation and are now focusing on testing, quality, and expanding the feature set appropriately.\n\nWe encourage you to try the software out in your own non-production Kubernetes clusters and share feedback on what you think and we are open to contributions to make it even better.\n\nToday we support autoscaling any HTTP traffic sent to a Kubernetes Services, but we are planning to support more specific traffic patterns including “north-south” with `Ingress` or the [Gateway API](https://github.com/kedacore/http-add-on/issues/33) and “east-west” with service-to-service communication or [service meshes](https://github.com/kedacore/http-add-on/issues/6).\n\nIn order to achieve this, we are working with the community to support as many existing products that exist today. For example, we will fully rely on the [Service Mesh Interface (SMI)](https://smi-spec.io/) specification which has become a solid industry standard for service-mesh workloads.\n\nBut why stop there? We are talking to various SIGs to determine if we need a general Traffic Metrics specification that takes the learnings from SMI spec and apply it to all traffic components for a unified traffic metrics approach in Kubernetes.\n\nWe’re also looking for feedback and contributors! Please feel free to [submit suggestions](https://github.com/kedacore/http-add-on/discussions/new) or [ask questions](https://github.com/kedacore/http-add-on/discussions/new), and if you’re interested in contributing, see our [contributing documentation](https://github.com/kedacore/http-add-on/blob/main/docs/contributing.md).\n\nLastly, we’d like to thank the following folks for building the initial prototype of the HTTP add-on and creating this project:\n\n- [Aaron Schlesinger](https://github.com/arschles)\n- [Lucas Santos](https://github.com/khaosdoctor)\n- [Aaron Wislang](https://github.com/asw101)\n- [Tom Kerkhove](https://github.com/tomkerkhove/) and the rest of the [KEDA core Maintainers](https://github.com/orgs/kedacore/teams/keda-maintainers)\n\nThanks for reading,\n\nAaron Schlesinger on behalf of the KEDA HTTP Add-on contributors and KEDA maintainers.\n"
  },
  {
    "path": "content/blog/2021-08-04-keda-cast-ai.md",
    "content": "+++\ntitle = \"How CAST AI uses KEDA for Kubernetes autoscaling\"\ndate = 2021-08-04\nauthor = \"Žilvinas Urbonas (CAST AI), Annie Talvasto (CAST AI), and Tom Kerkhove (KEDA)\"\naliases = [\n    \"/blog/how-cast-ai-uses-keda-for-kubernetes-autoscaling/\"\n]\n+++\n\n# How CAST AI uses KEDA for Kubernetes autoscaling\n\nKubernetes comes with several built-in [autoscaling mechanisms](https://cast.ai/blog/guide-to-kubernetes-autoscaling-for-cloud-cost-optimization/) - among them the Horizontal Pod Autoscaler (HPA). Scaling is essential for the producer-consumer workflow, a common use case in the IT world today. It’s especially useful for monthly reports and transactions with a huge load where teams need to spin up many workloads to process things faster and cheaper (for example, by using spot instances).\n\nBased on the provided CPU and memory-based metrics, the HPA can scale a setup up by adding more replicas - or down by removing idle replicas (this mechanism is called in/out). But it doesn’t have access to a source of metrics by default. The default HPA features aren’t flexible enough to cover custom scenarios like the producer/consumer. \n\nThis is where KEDA comes in.  \n\nOptimizing Kubernetes workloads for cost efficiency is the core mission of CAST AI. The platform helps teams reduce their cloud bills by up to 50% with no extra DevOps effort by automatically selecting optimal instances for running clusters, using spot instances whenever possible, and - of course - autoscaling with the help of KEDA.\n\nBy automating routine DevOps tasks via Terraform or CLI, CAST AI saves teams many hours they would spend on researching, installing, maintaining, patching, and observing their Kubernetes infrastructure. It also helps to prevent downtime with its multi-cloud capabilities.\n\n## KEDA & Horizontal Pod Autoscaler\n\nKEDA is available as a Policy/Add-on for clusters running in CAST AI. Users can easily install it by enabling the Horizontal Pod Autoscaler (HPA) policy in the console’s interface.\n\nKEDA includes two components:\n\n- operator - it watches Kubernetes for ScaledObject resources and configures the HPA accordingly,\n- metrics-apiserver - this is a bridge between Kubernetes and various scaling sources (including Prometheus).\n\nThese two components configure the HPA and set up custom metric sources, helping teams to autoscale almost any workload: Deployment, ReplicaSet, ReplicationController, or StatefulSet. KEDA supports autoscaling Jobs too.\n\n## Enabling KEDA in CAST AI\n\nTo autoscale with the Horizontal Pod Autoscaler, users need to enable the KEDA add-on on the Policies page available for every cluster in CAST AI.\n\n![CAST AI KEDA Policies](/img/blog/cast-ai-ref-case/cast-ai-keda-1.png \"Tom's title\")\n\nOnce enabled, KEDA will start working on a given cluster once users configure the associated scaled object. KEDA automatically changes pod replica counts based on the provided metrics.\n\n## Use case 1: Autoscaling based on CPU and/or Memory usage\n\nLet’s imagine that a user created a Deployment and a Service that they want to autoscale.\n\n```yml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: sample-app\n  labels:\n    app: sample-app\nspec:\n  # Note that we omit the replica count so\n  # when we redeploy, we wouldn't override\n  # replica count set by the autoscaler\n  #replicas: 1\n  selector:\n    matchLabels:\n      app: sample-app\n  template:\n    metadata:\n      labels:\n        app: sample-app\n    spec:\n      containers:\n      - image: luxas/autoscale-demo:v0.1.2\n        name: sample-app\n        ports:\n        - containerPort: 8080\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: sample-app\n  labels:\n    app: sample-app\nspec:\n  ports:\n  - port: 8080\n    name: http\n    targetPort: 8080\n    protocol: TCP\n  selector:\n    app: sample-app\n```\n\nNote that the user doesn’t specify a particular ReplicaCount.\n\nNow it’s time to set up a [CPU-based Autoscaler](https://keda.sh/docs/latest/scalers/cpu/):\n\n```yml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: sample-app\nspec:\n  scaleTargetRef:\n    name:          sample-app\n  minReplicaCount: 1        # Optional. Default: 0\n  maxReplicaCount: 10       # Optional. Default: 100\n  triggers:\n    # Either of the triggers can be omitted.\n    - type: cpu\n      metadata:\n        # Possible values: `Value`, `Utilization`, or `AverageValue`.\n        # More info at: https://keda.sh/docs/latest/scalers/cpu/#trigger-specification\n        type: \"Value\"\n        value: \"30\"\n    - type: memory\n      metadata:\n        # Possible values: `Value`, `Utilization`, or `AverageValue`.\n        # More info at: https://keda.sh/docs/latest/scalers/memory/\n        type: \"Value\"\n        value: \"512\"\n```\n\nDeployment autoscaling will be triggered by CPU or Memory usage. Users can specify any other trigger or remove the triggers altogether - for example, to autoscale only on the basis of the CPU or only using the Memory trigger.\n\n## Use case 2: Autoscaling based on a Prometheus metric\n\nCAST AI users can also autoscale their clusters based on the results of arbitrary Prometheus queries. CAST AI clusters come with Prometheus deployed out-of-the-box.\n\nSo, let’s deploy a sample application again - but this time, we’ll instruct Prometheus to scrape some metrics:\n\n\n```yml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: sample-app\n  labels:\n    app: sample-app\nspec:\n  selector:\n    matchLabels:\n      app: sample-app\n  template:\n    metadata:\n      labels:\n        app: sample-app\n      annotations:\n        # These annotations the main difference!\n        prometheus.io/path: \"/metrics\"\n        prometheus.io/port: \"8080\"\n        prometheus.io/scrape: \"true\"\n    spec:\n      containers:\n      - image: luxas/autoscale-demo:v0.1.2\n        name: sample-app\n        ports:\n        - containerPort: 8080\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: sample-app\n  labels:\n    app: sample-app\nspec:\n  ports:\n  - port: 8080\n    name: http\n    targetPort: 8080\n    protocol: TCP\n  selector:\n    app: sample-app\n```\n\nThen the user can deploy the Autoscaler.\n\n```yml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: sample-app\nspec:\n  scaleTargetRef:\n    name:          sample-app\n  minReplicaCount: 1        # Optional. Default: 0\n  maxReplicaCount: 10       # Optional. Default: 100\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://prom.castai:9090\n        threshold: '1'\n        # Note: query must return a vector/scalar single element response\n        query: sum(rate(http_requests_total{app=\"sample-app\"}[2m]))\n```\n\nLet’s check whether it all works by generating some load. You can see how the replica count increases.\n\n```bash\n# Deploy busybox image\nkubectl run -it --rm load-generator --image=busybox /bin/sh\n\n# Hit ENTER for command prompt\n\n# trigger infinite requests to the php-apache server\nwhile true; do wget -q -O- http://sample-app:8080/metrics; done\n\n# in order to cancel, hold CTRL+C\n# in order to quit, initiate CTRL+D sequence\n```\n\n## Batch processing with spot instances & KEDA\n\nLet’s go back to the producer-consumer problem we talked about earlier. Imagine that your company needs to process a large set of invoices at the end of each month. Your team has to spin up many workloads to process these jobs faster.\n\nYou switch on the Pod Autoscaler policy and then turn to the KEDA configuration.\n\n![CAST AI KEDA Policies](/img/blog/cast-ai-ref-case/cast-ai-keda-1.png)\n\nNote: The KEDA-based setup can also be used with CAST AI’s cluster autoscaler and spot instances to scale compute-intensive workloads in a cost-effective way. This is done by enabling the Unschedulable pods and Spot Instances policies. By enabling the node deletion policy, users ensure that idle instances are removed immediately.\n\nThe policy settings above will help to achieve cost savings for workloads like batch data processing. By moving data processing jobs to spot instances, teams can reduce their cloud bills and become more cloud-agnostic.\n\n![CAST AI KEDA Policies](/img/blog/cast-ai-ref-case/cast-ai-keda-2.png)\n\nIn the system depicted above, we simulated a real-world scenario of producer-consumer-based work processing. The queue length triggers our built-in KEDA component to create pods used to process jobs stored in the queue. These pods are all scheduled on spot instances. When jobs are done, empty nodes are deleted.\n\nCAST AI handles potential spot instance interruptions gracefully. If an interruption occurs and a job is in-flight, the job is marked as failed and reschedules on another node.\n\n## Looking towards the future with KEDA\n\nKEDA is an extremely powerful tool for scaling workloads horizontally. It allows workloads to scale to zero, taking up no resources when a job/process is not required. KEDA handles higher-order metrics with ease, enabling the next generation of auto-scaling solutions at CAST AI.\n\nSo, where are we going with KEDA next? One of the challenges to solve automatically is choosing scaling parameters. Settings such as minReplicaCount and maxReplicaCount, along with the trigger threshold, have to be set manually today. For the most part, these are educated estimates and trial-and-error experiments performed by the engineering team. CAST AI is working on making these settings more automated based on application performance and the reaction to change in settings.\n\nWe believe that is the next great KEDA challenge, so stay tuned for more!\n\n## Glossary:\n\n*Add-on*\n\nAn add-on is an application that helps another application perform more tasks or do it better. Apart from KEDA, CAST AI offers access to add-ons like Grafana, Grafana Loki, Evictor, Ingress Nginx, Cert Manager, Kubernetes Dashboard.\n\n*Policy*\n\nCAST AI users can turn on and manage policies that automate the process of scaling clusters up and down to optimize and reduce costs.\n"
  },
  {
    "path": "content/blog/2022-02-09-predictkube-scaler.md",
    "content": "+++\ntitle = \"Introducing PredictKube - an AI-based predictive autoscaler for KEDA made by Dysnix\"\ndate = 2022-02-14\nauthor = \"Daniel Yavorovych (Dysnix), Yuriy Khoma (Dysnix), Zbynek Roubalik (KEDA), Tom Kerkhove (KEDA)\"\naliases = [\n\"/blog/introducing-predictkube-for-keda-by-dysnix\"\n]\n+++\n\n## Introducing PredictKube—an AI-based predictive autoscaler for KEDA made by Dysnix\n\n[Dysnix](https://dysnix.com/) has been working with high-traffic backend systems for a long time,\nand the efficient scaling demand is what their team comes across each day.\nThe engineers have understood that manually dealing with traffic fluctuations and preparations of infrastructure is\ninefficient because you need to deploy more resources _before_ the traffic increases,\nnot at the moment the event happens. This strategy is problematic for two reasons: first, because it's often too late to scale when traffic has already arrived and second, resources will be overprovisioned and idle during the times that traffic isn't present.\n\nAnd when it comes to deciding how to wrap up this solution, Dysnix decided to rely on KEDA as it is the most\nuniversal and applicable component for application autoscaling in Kubernetes.\n\nKEDA is being used as a component on the client side of PredictKube that is responsible for transferring requests\nand scaling replicas.\n\n## Dysnix's PredictKube integrates with KEDA\n\nDysnix has built [PredictKube](https://predictkube.com/), a solution that can be used as a KEDA scaler that\nis responsible for resource balancing, and an AI model that has learned to react proactively to patterns of traffic activity,\nto help with both in-time scaling and solving the problem of overprovision.\n\n![Overprovision](/img/blog/predictkube-scaler/overprovision.png \"Overprovision\")\n\nThe predictive autoscaling process is possible thanks to an AI model that observes the requests-per-second (RPS)\nor CPU values for a period of time during a project and then shows the trend for up to 6 hours.\nPredictKube used customer and open data sources (we used data sets like [HTTP NASA logs](ftp://ita.ee.lbl.gov/html/contrib/NASA-HTTP.html)) to train the model and be specific about the cloud data and traffic trends.\n\nWith this tool, Dysnix wants to decrease costs on the projects, analyze the data about traffic more efficiently,\nuse cloud resources more responsibly, and build infrastructures that are &quot;greener&quot; and more performative\n(with fewer downtimes and delays) than others.\n\n## How does PredictKube work?\n\nPredictKube works in two parts:\n\n1. **On the KEDA side**\n   The interface connects via API to the data sources about your traffic.\n   PredictKube uses [Prometheus](https://prometheus.io/)—the industry standard for storing metrics.\n   There, it anonymizes the data about the traffic on the client's side before sending it to the API,\n   where the model then works with information that is completely impersonal.\n2. **On the AI model side**\n   Next, it is linked with a prediction mechanism—the AI model starts to get data about things that happen in\n   your cloud project. Unlike standard rules-based algorithms such as Horizontal Pod Autoscaling (HPA),\n   PredictKube uses Machine Learning models for time series data predicting, like CPU or RPS metrics.\n\nThe more data you can provide to it from the start, the more precise the prediction will be. The 2+ weeks data will be enough for the beginning.\n\n![PredictKube Scaler Diagram](/img/blog/predictkube-scaler/diagram.png)\n\nThe rest is up to you! You can visualize the trend of prediction in, for example, [Grafana](https://grafana.com/).\n\n## Launch of PredictKube\n\n1. [Install KEDA](https://keda.sh/docs/latest/deploy/)\n2. Get PredictKube API Key\n- Go to the [PredictKube website](https://predictkube.com/)\n- Register to get the API key in your email\n3. Create PredictKube Credentials secret[​](https://docs.predictkube.com/quickstart-with-keda#create-predictkube-credentials-secret)\n\n```bash\nAPI_KEY=\"<change-me>\"\n$ kubectl create secret generic predictkube-secrets --from-literal=apiKey=${API_KEY}\n```\n\n4. Configure Predict Autoscaling[​](https://docs.predictkube.com/quickstart-with-keda#configure-predict-autoscaling)\n\n```yml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\nspec:\n  secretTargetRef:\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: example\nspec:\n  scaleTargetRef:\n    name: example-app\n  pollingInterval: 60\n  cooldownPeriod: 300\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"  # We recommend using a minimum of a 7-14 day time window as historical data\n      prometheusAddress: http://kube-prometheus-stack-prometheus.monitoring:9090\n      query: sum(irate(http_requests_total{pod=~\"example-app-.*\"}[2m]))\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: '2000' # Value to start scaling for\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n\n\n5. Check the status and get stats[​](https://docs.predictkube.com/quickstart-with-keda#get-stats)\n\nTo check the configuration and status of the scaling created in the previous step, use the following command:\n\n```bash\n$ kubectl get scaledobject example\n```\n\nTo get stats to use for the scaling, use the following command:\n\n```bash\n$ kubectl get hpa example\n```\n\nNow you can look at how scaling works at a graph in your visualization tool.\nThis is an example of a graph Dysnix gets in one of their projects after using PredictKube:\n\n![Grafana dashboard](/img/blog/predictkube-scaler/grafana.png \"Grafana dashboard\")\n\nOn this graph, you'll see the graphs of stats for the environment with 2 hours cooldown period.\nThe green trend shows predicted replicas number, a yellow one—ready replicas at a certain moment,\nand the ideal—the blue trend—showing the closest replicas number covering the RPS trend.\nIf you need a template of such a dashboard to make your own, feel free to contact [Daniel](https://github.com/daniel-yavorovich) to get one.\n\nAfter everything is connected and deployed, you'll be able to change the time frame you're observing or just monitor the data as it comes.\n\n## What's next?\n\nWith this release, Dysnix has created the first milestone of predictive autoscaling for Kubernetes workloads.\nThe team hopes you'll find it interesting and help to test it and improve it.\nIf you have any questions to ask about the core functionality of PredictKube,\nyou may contact the developers' team [here](https://predictkube.com/contact).\nAnd for all KEDA-related issues, share your feedback [via GitHub](https://github.com/kedacore/keda/discussions/2605).\n\nIn the future, PredictKube plans to add more integrations with other data sources to autoscale\nbased on other configurations of the projects. Also, there is an idea for implementing\nan event-based predictive scaling to make it possible to react on not only a trend but event appearance.\n\nYou can contact the Dysnix team with any questions concerning the mechanics of PredictKube\nor learn more about the data usage in its [privacy policy](https://predictkube.com/privacy-policy).\nThe following people will be happy to help:\n\n- [Daniel Yavorovych](https://github.com/daniel-yavorovich) — KEDA integration and Kubernetes-related questions;\n- [Yurij Khoma](https://www.linkedin.com/in/yuriy-khoma-5657a461/) — can comment more about the AI model that was created.\n\nThanks for reading,\n\nDaniel Yavorovych and Yuriy Khoma on behalf of the PredictKube developers team.\n"
  },
  {
    "path": "content/blog/2022-03-10-how-zapier-uses-keda.md",
    "content": "+++\ntitle = \"How Zapier uses KEDA\"\ndate = 2022-03-10\nauthor = \"Ratnadeep Debnath (Zapier)\"\naliases = [\n\"/blog/how-zapier-uses-keda\"\n]\n+++\n\n[RabbitMQ](https://www.rabbitmq.com/) is at the heart of Zap processing at [Zapier](https://zapier.com). We enqueue messages to RabbitMQ for each step in a Zap. These messages get consumed by our backend workers, which run on [Kubernetes](https://kubernetes.io). To keep up with the varying task loads in Zapier we need to scale our workers with our message backlog.\n\nFor a long time, we scaled with CPU-based autoscaling using Kubernetes native Horizontal Pod Autoscale (HPA), where more tasks led to more processing, increasing CPU usage, and triggering our workers' autoscaling. It seemed to work pretty well, except for certain edge cases.\n\nWe do a lot of [blocking I/O](https://medium.com/coderscorner/tale-of-client-server-and-socket-a6ef54a74763) in Python (we don’t use an event-based loop in our workers written in Python). This means that we could have a fleet of workers idling on blocking I/O with low CPU profiles while the queue keeps growing unbounded, as low CPU usage would prevent autoscaling from kicking in. In a situation where workers are idle while waiting for I/O, we could have a growing backlog of messages that a CPU-based autoscaler would miss. This situation allowed a traffic jam to form and introduce delays in processing Zap tasks.\n\nIdeally, we would like to scale our workers on both CPU and our backlog of ready messages in RabbitMQ. Unfortunately, Kubernetes’ native HPA does not support scaling based on RabbitMQ queue length out of the box. There is a potential solution by collecting RabbitMQ metrics in Prometheus, creating a custom metrics server, and configuring HPA to use these metrics. However, this is a lot of work and why reinvent the wheel when there’s KEDA.\n\nWe have installed KEDA in our Kubernetes clusters and started opting into KEDA for autoscaling. Our goal is to autoscale our workers not just based on CPU usage, but also based on the number of ready messages in RabbitMQ queues they are consuming from.\n\nAt Zapier, we use KEDA to autoscale our workers not just based on CPU usage, but also based on the number of ready messages in RabbitMQ queues they are consuming from. We monitor our KEDA setup in Grafana using Prometheus metrics, and use Prometheus rules to alert on errors. Using KEDA to autoscale our workers significantly prevented delays in our Zap processing due to blocked I/O calls. We are slowly updating apps at Zapier to use KEDA.\n\n**Read the rest of this [post on how Zapier uses KEDA](https://www.cncf.io/blog/2022/01/21/keda-at-zapier/) on the Cloud Native Computing Foundation blog.**\n"
  },
  {
    "path": "content/blog/2022-08-10-keda-2.8.0-release.md",
    "content": "+++\ntitle = \"Announcing KEDA v2.8 🎉\"\ndate = 2022-08-10\nauthor = \"Jeff Hollan (KEDA), Tom Kerkhove (KEDA)\"\naliases = [\n\"/blog/2.8.0-release\"\n]\n+++\n\nWe recently completed our most recent release: 2.8.0 🎉!\n\nHere are some highlights:\n\n- Introduction of new AWS DynomoDB Streams & NATS JetStream scalers.\n- Introduction of new Azure AD Workload Identity authentication provider.\n- Support for specifying `minReplicaCount` in ScaledJob.\n- Support to customize the HPA name.\n- Support for permission segregation when using Azure AD Pod / Workload Identity\n- Additional features to various scalers such as AWS SQS, Azure Pipelines, CPU, GCP Stackdriver, Kafka, Memory, Prometheus\n\nHere are the new deprecation(s) as of this release:\n\n- `rolloutStrategy` in ScaledJob is deprecated in favor of `rollout.strategy`\n\nLet's have a closer look.\n\n## New & Improved Scalers\n\nKEDA now has 50+ built-in scalers, giving you instant access to provide event driven scale across a variety of sources. New with this release are:\n- AWS DynamoDB Streams ([docs](https://keda.sh/docs/2.8/scalers/aws-dynamodb-streams/))\n- NATS JetStream ([docs](https://keda.sh/docs/2.8/scalers/nats-jetstream/))\n\nIn addition to new scalers, various new features and improvements were added to AWS SQS, Azure Pipelines, CPU, GCP Stackdriver, Kafka, Memory, and Prometheus scalers.\n\n## Activation and Scaling Thresholds\n\nPreviously in KEDA, when scaling from 0 to 1, KEDA would \"activate\" (scale to 1) a resource when *any* activity happened on that event source. For example, if using a queue, a single message on the queue would trigger activation and scale.\n\nAs of this release, we now allow you to set an `activationThreshold` for many scalers which is the metric that must be hit before scaling to 1.\n\nThis would allow you to delay scaling up to 1 until *n* number of messages were unprocessed. This pairs with other thresholds and target values for scaling from 1 to *n* instances, where the HPA will scale out to *n* instances based on the current event metric and the defined threshold values.\n\nDetails on thresholds and the new activation thresholds can be found [in the KEDA concept docs](https://keda.sh/docs/2.8/concepts/scaling-deployments/#activating-and-scaling-thresholds)\n\n## Introducing support for Azure AD Workload Identity & identity segregation\n\nOne critical piece of functionality in KEDA is the ability to authenticate with different event sources. The `TriggerAuthentication` CRD allows you to define secure secrets and identities to use within your scaled objects and jobs.\n\nAs of v2.8.0, you can now use [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) which is supported by using `azure-workload` as a valid pod identity provider.\n\nWe want to strive to be as secure as we can and reduce the risk of breach by allowing end-users to use least-privilege principle. This is crucial because KEDA is installed once and available to the whole Kubernetes cluster. However, identities used for Azure AD Pod Identity and Azure AD Workload Identity providers are applied on KEDA itself which means it can be used by all applications.\n\nThat is why we are **introducing segregation of permissions within KEDA and its used identity/identities**.\n\nThis means you don't have to grant the KEDA pod too many permissions to too many sources, and can now specify an `identityId` in your `TriggerAuthentication` allowing to define the identity to use which has more scoped permissions for specific triggers.\n\nMore details can be found in the KEDA [Authentication documentation](https://keda.sh/docs/2.8/concepts/authentication/).\n\n## `rolloutStrategy` in ScaledJob is deprecated in favor of `rollout.strategy`\n\nAs of this release, `rolloutStrategy` in ScaledJob is deprecated in favor of `rollout.strategy` and ask all end-users to migrate to `rollout.strategy` instead.\n\nThis change has been introduced so that end-users have more control over how rollouts are performed and have introduced new capabilities such as `rollout.propagationPolicy` to compliment this.\n\nEnd-users who are still using `rolloutStrategy` will not be impacted, until it will be removed in KEDA 3.x.\n\nLearn more in our [new documentation](https://keda.sh/docs/2.8/concepts/scaling-jobs/) and join our [GitHub Discussion](https://github.com/kedacore/keda/discussions/3552) if you have questions/problems migrating.\n\n## Simplified end-to-end testing experience for contributors\n\nWe've added some new features to our end to end testing and PR process. The test framework used to coordinate end to end tests was moved from TypeScript to Go, so contributors can stick within a single language for the codebase. We also improved the Pull Request process so that all PRs will be blocked until e2e tests pass or until a label `ok-to-merge` is added, and created a new team `keda-e2e-test-executors` who can now trigger end to end tests to run.\n\n## And more...\n\nThis is just some of the highlights for the latest release. You can find the full release notes can be [found here](https://github.com/kedacore/keda/releases/tag/v2.8.0).\n\nThe next KEDA release is scheduled for the first week of November 2022.\n\nThanks to everyone for helping make KEDA better!"
  },
  {
    "path": "content/blog/2022-09-27-http-add-on-is-on-hold.md",
    "content": "+++\ntitle = \"HTTP add-on is looking for contributors by end of November\"\ndate = 2022-09-27\nauthor = \"Tom Kerkhove (KEDA)\"\naliases = []\n+++\n\nOn Nov 25, 2020, we started the HTTP add-on based on [@arschles](https://github.com/arschles) his initial POC which closed a big gap in KEDA's story - HTTP autoscaling without a dependency on an external system, such as Prometheus.\n\nTo this day, the autoscaling community has a very high demand for a solution in this area that auto scales and works in the same manner as the KEDA core.\n\nWith the add-on, we want to cover all traffic patterns ranging from ingress, to service meshes and service-to-service communication and make it super simple to autoscale (and with scale-to-zero support).\n\nAs time passed by, we've seen [@arschles](https://github.com/arschles) lead the HTTP add-on to a beta stage and have defined the [requirements for it to become a GA add-on](https://github.com/orgs/kedacore/projects/6/views/9).\n\nUnfortunately we have seen very few contributions to the project and [@arschles](https://github.com/arschles) has switched roles and is unable to maintain it anymore.\n\n📢 **Because of that, we are doing an active call for contributors and will assess the future of the HTTP add-on by the end of November based on the community and (hopefully) contribution growth. Until then, the project is on-hold.** 📢\n\n**If we do not have at least 3 contributors take charge we will have to see what alternatives we have.**\n\nWe'd also want to take the time to say a big thank you to [@arschles](https://github.com/arschles) for his hard work on this and hopefully we can continue taking it forward!\n\nJoin our discussion on [GitHub](https://github.com/kedacore/http-add-on/discussions/523) if you want to stay up-to-date or want to get involved.\n"
  },
  {
    "path": "content/blog/2022-12-12-keda-2.9.0-release.md",
    "content": "+++\ntitle = \"Announcing KEDA v2.9 🎉\"\ndate = 2022-12-12\nauthor = \"Jeff Hollan (Snowflake), Tom Kerkhove (Microsoft) and Zbynek Roubalik (Red Hat)\"\naliases = [\n\"/blog/releases/2.9.0\"\n]\n+++\n\nWe recently completed our most recent release: 2.9.0 🎉!\n\nHere are some highlights:\n\n- Newly published Deprecations and Breaking Change policy ([docs](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md))\n- Introduce new CouchDB, Etcd & Loki scalers\n- Introduce off-the-shelf Grafana dashboard for application autoscaling\n- Introduce improved operational metrics in Prometheus\n- Introduce capability to cache metric values for a scaler during the polling interval (experimental feature)\n- Performance improvements and architecture changes on how metrics are exposed to Kubernetes\n- Azure Key Vault authentication provider now supports pod identities for authentication\n- A ton of new features and fixes for some of our 50+ scalers\n\nPotential breaking changes and deprecations include:\n- As per our [support policy](https://github.com/kedacore/governance/blob/main/SUPPORT.md), Kubernetes v1.23 or above is required and support for Kubernetes v1.22 or below was removed ([docs](https://keda.sh/docs/2.9/operate/cluster/#kubernetes-compatibility))\n- Upgrading the API version of managed HPA objects from `autoscaling/v2beta2` to `autoscaling/v2`\n- Prometheus metrics on KEDA Metric Server are deprecated in favor of Prometheus metrics on KEDA Operator ([#3972](https://github.com/kedacore/keda/issues/3972) | [Discussion](https://github.com/kedacore/keda/discussions/3973))\n\nYou can keep an eye and join the discussion for future breaking changes and deprecations [in our GitHub issues](https://github.com/kedacore/keda/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Abreaking-change).\n\n## New & Improved Scalers\n\nKEDA now has 50+ built-in scalers, giving you instant access to provide event driven scale across a variety of sources.\n\nNew scalers in this release are:\n- Etcd ([docs](https://keda.sh/docs/scalers/etcd/))\n- CouchDB ([docs](https://keda.sh/docs/scalers/couchdb/))\n- Loki ([docs](https://keda.sh/docs/scalers/loki/))\n\nIn addition to new scalers, various new features and improvements were added to Kafka, Azure Event Hubs, Azure Pipelines, GCP Storage, Metrics, NATS Jetstream, Prometheus, Pulsar, Azure Blob, GCP Stackdriver, and New Relic scalers.\n\nHere are a few improvement highlights:\n\n- **AWS Scalers:** Introduce new AWS endpoint URL settings\n- **Apache Kafka Scaler:** Support for SASL/OAuth bearer authentication and/orlimiting Kafka partitions KEDA will monitor\n- **Azure Event Hubs Scaler:** Support Azure Active Directory Pod & Workload Identity authentication for Storage Blobs, Dapr checkpointing and using connection strings for Event Hub namespace instead of the Event Hub itself.\n- **Azure Service Bus Scaler:** Support for Shared Access Signature (SAS) tokens for authentication and use of regex in `queueName` / `subscriptionName`\n- **ElasticSearch Scaler:** Support for Elastic Cloud\n- **GCP Storage Scaler:** Support for blob prefix & delimiters\n- **Metrics API Scaler:** Support for unsafeSsl parameter to skip certificate validation when connecting over HTTPS\n- **NATS Jetstream Scaler:** Support for clustered scenarios\n- **NATS Scalers:** Support HTTPS protocol\n- **Prometheus Scaler:** Introduce skipping of certificate check for unsigned certs\n- **Pulsar Scaler:** Add support for basic and bearer token authentication along with support for partitioned topics\n\nDetails on the underlying fixes can be found in the [changelog](https://github.com/kedacore/keda/blob/main/CHANGELOG.md#v290).\n\n## Production-grade operating experience for autoscaling applications\n\nThere are a number of improvements into the ways KEDA provides operational information in Prometheus and how you can consume it.\n\nFor starters, **our operator now exposes Prometheus metrics** which can be scraped on port `8080` at `/metrics`. It provides the same set of metrics as the metric server (although renamed) offers today, in addition to a few new metrics and the introduction of a `ScalerName` label.\n\nThe metrics are moving given we are changing how KEDA is integrating with external systems so that we can improve the performance and reduce the load on those external systems.\n\nAs part of this, **we are deprecating the KEDA-specific metrics in our metric server** and recommend end-users to use the metrics in the operator. Join our [conversation there](https://github.com/kedacore/keda/discussions/3973).\n\nNext, we have **introduced `keda_resource_totals` and `keda_trigger_totals` as metrics** that provide insights into your autoscaling landscape and the various autoscaling triggers that are being used.\n\nMetrics are great - But they have to be consumed. That's why we **introduced a new Grafana dashboard allows end-users to easily visualize the KEDA metrics in Grafana** to see how your applications are scaling:\n\n![Grafana Dashboard](/img/blog/v2.9-release/grafana-dashboard.png)\n\nLastly, **end-users using `ScaledJobs` can now see what the minimum replica count is when inspecting resources** through the Kubernetes API.\n\nLearn more about our available Prometheus metrics and our Grafana dashboard in our [docs](https://keda.sh/docs/operate/prometheus/).\n\n## Change in the architecture and metrics caching\n\nIn this release we focused on performance improvements. Let's talk about these changes: KEDA has two main components - the Operator and the Metrics Server. The Operator monitors ScaledObjects and ScaledJobs resources, and checks activity on the external service. The Metrics Server handles requests and queries about metric values used for scaling from Kubernetes' Horizontal Pod Autoscaler (HPA) by checking the external service.\n\nIn previous versions of KEDA, each component needed to handle its own connection to the external service. In version 2.9, we have changed this and moved the connection logic to the Operator component. We are now using gRPC for the connection between the Metrics Server and Operator. This has several benefits, including reduced load on the external service, as there is only one connection from the Operator.\n\nWe have also introduced an experimental feature called metrics value caching. This caches the values in the Operator and can be reused in future. It can even further reduce the load on the external service. By default, Kubernetes' HPA asks for a metric value every few seconds (as defined b `--horizontal-pod-autoscaler-sync-period` flag set by Kuberentes admins, which is usually set to 15 seconds). This can create unnecessary load on the external service. Caching metric values per trigger in a ScaledObject can help to overcome this problem. This is an optional feature, and can be enabled by setting the `useCachedMetrics` flag, then metric values are cached during polling interval as defined by `pollingInterval` flag and request comming from HPA to KEDA Metrics Server are served from this cache.\n\nWe are excited about the potential uses for this feature in the future, including using AI and machine learning models to affect metric values. Stay tuned for more updates and improvements in future releases of KEDA.\n\n## New ways to authenticate\n\nIn this release we have added some additional configuration options for triggers:\n\nAzure Key Vault authentication provider now allows end-users to use pod identities for authentication for improved simplicity & security:\n\n```diff\nazureKeyVault:                                          # Optional.\n  vaultUri: https://keda.vault.azure.net\n+ podIdentity:\n+   provider: azure-workload\n    # Optionally, you can specify a user-assigned identity: identityId: <identity-id>\n  secrets:                                              # Required.\n  - parameter: connection\n    name: ServiceBus-ConnectionString  \n```\n\nOur Azure AD Pod Identity authentication now also has improved logs around integration with `aad-pod-identity` for simplified troubleshooting.\n\n## And more...\n\nThis is just some of the highlights for the latest release. You can find the full release notes [here](https://github.com/kedacore/keda/releases/tag/v2.9.0).\n\nThe next KEDA release is [scheduled for March 2023](https://github.com/kedacore/keda/blob/main/ROADMAP.md).\n\nThanks to everyone for helping make KEDA better!\n"
  },
  {
    "path": "content/blog/2023-05-02-certificate-improvements.md",
    "content": "+++\ntitle = \"Securing autoscaling with the newly improved certificate management in KEDA 2.10\"\ndate = 2023-05-16\nauthor = \"Jorge Turrado (SCRM Lidl International Hub)\"\naliases = [\n\"/blog/exploring-new-certificate-management\"\n]\n+++\n\nRecently, we have release KEDA v2.10 that introduced a key improvement for managing certificates and your autoscaling security: \n\n- Encryption of any communication between KEDA components.\n- Support for providing your own certificates for internal communications.\n- Support for using customs certificate authorities (CA).\n\nWith these new improvements, we can dramatically improve the security between KEDA components, the Kubernetes API server and scaler sources. Let's take a closer look.\n\n## Where do we come from?\n\nKEDA is a component that runs on kubernetes, receiving request from kubernetes API server (from the HPA Controller) but also integrates with multiple external sources (upstreams). \n\nTo improve our integration with Kubernetes' API server, we decided to skip the certificate validation using a built-in property, `insecureSkipTLSVerify`. Thanks to it, we could use self generate the metrics server certificate on every restart, not having to manage it and simplifying the process, but using at least an encrypted channel between kubernetes and KEDA metrics server.\n\nThe second case was more complicated... We really trust in the encryption as the way to achieve secure connections, so we wanted to support encrypted connection wherever a user wants to use them, but using self-signed certificates is a really common scenario and that was complex to manage. As a first and fast option, we decided to support an extra parameter in some scalers to skip the certificate validation, allowing these scenarios.\n\nBefore version 2.9, KEDA was composed by 2 different components with totally different goals, the operator and the metrics server. As both components were independent by design, so we didn't need to secure anything between them, but it changed in version v2.9. [As we announced in KEDA v2.9 release](/blog/releases/2.9.0), we introduced an important change in the architecture. Now we have 2 components, but they are strong related and they need to have a secured channel for the internal communications. At that point, we decided to release v2.9 with this gap in terms of encryption for internal communications, but having the commitment of solving this for the next version.\n\n## Securing connections between KEDA components and Kubernetes API server\n\nAs part of version 2.10, we have released a mechanism to generate a self-signed certificate that will be used to encrypt all the traffic between various KEDA components but also patching `apiservice` and the new validating webhook to include the `caBundle`. Thanks to this mechanism, we can encrypt all the traffic between KEDA components with mutual TLS (TLSv1.3). Additionally, it allows us to remove the `insecureSkipTLSVerify` flag for the Kubernetes API Server making all our communications more secure between Kubernetes and KEDA.\n\nBy default, KEDA uses self-signed certificates for various things and the operator is in charge of generating and rotating them. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that is mounted to all KEDA components to `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nThe KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, end-user specific certificates can be stored in the `kedaorg-certs` secret and will automatically update all components (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nWith our recent architecture changes in v2.9, our operator is the only component that needs to interact with the (scaler) dependencies. This has been the last requirement for solving the problem of registering CAs to avoid the usage of `unsafeSsl` because even though it works, it also allows any certificate, which is not totally secure.\n\nTo overcome this problem, KEDA supports registering custom CAs that will be used by various SDKs where possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder.\n\n## A practical example using helm\n\nWith KEDA, we strive to make application autoscaling simple and that is why we have integrated cert-manager manifests as an optional component of our Helm chart. By doing so, you can use cert-manager to generate, rotate and patch services as part of the Helm installation (cert manager needs to be installed up front).\n\n```yaml\ncertificates:\n  autoGenerated: false # disables the cert-generation by the operator\n  certManager:\n    enabled: true # enables the certificate generation using cert manager\n    generateCA: true # uses a self-signed generated CA\n    # caSecretName: \"kedaorg-ca\"\n```\n\nTo provide a CA to be used for generating certificates, you can store it as a secret (in the same namespace where KEDA is installed) and configure the secret. This will register an issuer based on it for generating the certificates.\n\n```yaml\ncertificates:\n  autoGenerated: false # disables the cert-generation by the operator\n  certManager:\n    enabled: true # enables the certificate generation using cert manager\n    generateCA: false # uses a self-signed generated CA\n    caSecretName: \"kedaorg-ca\" # secret name where the CA is stored\n```\n\n> Note: As KEDA requires the services to be correctly patched, when the cert manager integration is enabled, the manifests are annotated. If you provide a CA via secret, the secret has to be annotated with `cert-manager.io/allow-direct-injection: \"true\"`. Otherwise, the cert manager cannot patch the resources with the CA.\n\n## Conclusion\n\nThe improvements made to certificate management in KEDA 2.10 are a significant step forward in enhancing security and reliability, but they are not the only ones. We are working to make KEDA even more secure by default with small actions like limiting the default minimum TLS version or correctly using security contexts in Kubernetes.\n\nIf you want to dive deeper, don't hesitate to check the [repo changelog](https://github.com/kedacore/keda/blob/main/CHANGELOG.md), where every change is listed. And stay tuned to future posts about other security tips! ;)"
  },
  {
    "path": "content/blog/2023-05-04-keda-survey.md",
    "content": "+++\ntitle = \"Help shape the future of KEDA with our survey 📝\"\ndate = 2023-05-04\nauthor = \"KEDA Maintainers\"\naliases = [\n\"/blog/keda-survey\"\n]\n+++\n\nAs maintainers, we are always eager to learn who is using KEDA ([become a listed end-user!](https://github.com/kedacore/keda#adopters---become-a-listed-keda-user)) and how they are using KEDA to scale their cloud-native workloads.\n\nOur job is to make sure that your are able to scale the workloads that you run with as less friction as possible, production-grade security, insights on what is going on, etc.\n\nIn order to be successful, we need to learn how big of KEDA deployments end-users are running, what is causing frustration and what we can improve. This is why we have created a survey to gain more insights and make KEDA better.\n\n**If you want to help shape KEDA's future, feel free to fill in [our 2-minute survey](https://forms.gle/nC393JzCqK1evjcH9).**\n\nProud of your autoscaling infrastructure? You're more then welcome to show it in our [KEDA deployment show & tell discussion](https://github.com/kedacore/keda/discussions/4410) as well!\n\nThank you for helping make KEDA better!\n"
  },
  {
    "path": "content/blog/2023-08-22-keda-cncf-graduation.md",
    "content": "+++\ntitle = \"KEDA is graduating to CNCF Graduated project 🎉\"\ndate = 2023-08-22\nauthor = \"KEDA Maintainers\"\naliases = [\n\"/blog/keda-cncf-graduation\"\n]\n+++\n\nIn 2019, KEDA embarked on a mission to make application autoscaling on Kubernetes dead-simple. Our aim was to make sure that every Kubernetes platform can use it to scale applications without having to worry about the underlying autoscaling infrastructure.\n\nAs part of that mission, we wanted to build a vendor-neutral project that is open to everyone and nicely integrates with other tools. Because of that, the KEDA maintainers decided that the Cloud Native Computing Foundation (CNCF) was a natural fit and got accepted as a sandbox project in 2020.\n\nKEDA started evolving and became a more mature autoscaler which came with more scalers out-of-the-box and introduced new concepts such as scaled jobs, trigger authentication, operational metrics, and more. The community started growing as well, the project governance matured and KEDA became a CNCF Incubation project in 2021.\n\nIn the past year and a half, KEDA started focussing on making it easier to use for larger enterprises and use KEDA at-scale serving thousands of scaled objects with low performance impact.\n\nToday is another important milestone in KEDA's journey - **We are excited to announce that the [CNCF has accepted to move KEDA to a CNCF Graduated project](https://www.cncf.io/announcements/2023/08/22/cloud-native-computing-foundation-announces-graduation-of-kubernetes-autoscaler-keda/) next to projects such as Kubernetes, Prometheus, Istio and others! 🎉.**\n\nIt has been great to see how KEDA has been adopted and is being used by more than 45+ listed end-users:\n\n![architecture diagram](/img/blog/keda-cncf-graduation/keda-graduation-end-users.gif)\n\nWe would like to thank everyone who has contributed to KEDA, installed KEDA, gave feedback or talked about it in the community. Additionally, we want to thank our CNCF TOC sponsors (Cathy Zhang & Ricardo Rocha) for their support, help and trust in our project as part of the graduation process!\n\nWe are excited about this new phase of KEDA and are looking forward to making KEDA even better!\n\nHappy scaling,\n\nKEDA maintainers.\n"
  },
  {
    "path": "content/blog/2025-09-15-gcp-deprecations.md",
    "content": "+++\ntitle = \"Google Cloud deprecations\"\ndate = 2025-09-15\nauthor = \"Jorge Turrado (SCRM Lidl International Hub)\"\naliases = [\n\"/blog/gcp-deprecations\"\n]\n+++\n\nOne year ago, Google Cloud deprecated its [Monitoring Query Language](https://cloud.google.com/monitoring/mql) in favor of a PromQL-based API:\n\n> Announcement: Starting on October 22, 2024, Monitoring Query Language (MQL) will no longer be a recommended query language for Cloud Monitoring. Certain usability features will be disabled, but you can still run MQL queries in Metrics Explorer, and dashboards and alerting policies that use MQL will continue to work. For more information, see the [deprecation notice for MQL](https://cloud.google.com/stackdriver/docs/deprecations/mql).\n\n\nAlthough the deprecation announcement also says that \"***MQL is not being shut down**. You will still be able to create and run MQL queries, and dashboards and alerting policies that use MQL queries will continue to work.*\"\nwe have decided to deprecate our current GCP scalers which rely on MQL (\"[Cloud Tasks](https://keda.sh/docs/latest/scalers/gcp-cloud-tasks/)\", \"[Pub/Sub](https://keda.sh/docs/latest/scalers/gcp-pub-sub/)\" and \"[Stackdriver](https://keda.sh/docs/latest/scalers/gcp-stackdriver/)\") keeping those that don't rely on MQL but use other SDKs, untouched (currently only \"[Storage](https://keda.sh/docs/latest/scalers/gcp-storage/)\" remains supported).\n\nDoes this mean KEDA no longer supports Google Cloud Platform? Absolutely not! We are committed to making the autoscaling dead simple on any vendor! In this case, we suggest moving the current deprecated scalers to [Prometheus scaler](https://keda.sh/docs/latest/scalers/prometheus/) for GCP.\n\n> **Note**: GCP exposes the metrics via Prometheus endpoints without any extra configuration or services; you don't need to deploy anything else to get these metrics via Prometheus.\n\n**We don't plan to remove these affected scalers as long as GCP supports MQL** but we strongly encourage migrating to a Prometheus-like approach to avoid service disruptions in case of any change on GCP.\n\n## How to migrate\n\nThe migration path differs slightly depending on the scaler, but these are some examples:\n\n### Migrate Google Cloud Platform Cloud Tasks\n\nFrom the current trigger spec:\n- `projectID` is not included as part of `serverAddress` value (`https://monitoring.googleapis.com/v1/projects/{{projectID}}/location/global/prometheus`).\n- `value` and `activationValue` are replaced by `threshold` and `activationThreshold`.\n- `queueName` is now included as part of `query` value (`{\"__name__\"=\"cloudtasks.googleapis.com/queue/depth\",\"monitored_resource\"=\"cloud_tasks_queue\",\"queue_id\"=\"{{queueName}}\"}`).\n- `GoogleApplicationCredentials`, `credentialsFromEnv`, `credentialsFromEnvFile` don't change.\n\nFor example, these scalers are equivalent:\n```yaml\n- type: gcp-cloudtasks\n  metadata:\n    projectID: \"my-keda-project\"\n    queueName: \"consumer-queue\"\n    value: \"5\"\n    activationValue: \"0\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n```yaml\n- type: prometheus\n  metadata:\n    serverAddress: https://monitoring.googleapis.com/v1/projects/my-keda-project/location/global/prometheus\n    query: '{\"__name__\"=\"cloudtasks.googleapis.com/queue/depth\",\"monitored_resource\"=\"cloud_tasks_queue\",\"queue_id\"=\"consumer-queue\"}'\n    threshold: \"5\"\n    activationThreshold: \"0\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n### Migrate Google Cloud Platform Stackdriver\n\nFrom the current trigger spec:\n- `projectID` is not included as part of `serverAddress` value (`https://monitoring.googleapis.com/v1/projects/{{projectID}}/location/global/prometheus`).\n- `targetValue ` and `activationTargetValue` are replaced by `threshold` and `activationThreshold`.\n- `filter` is replaced by `query`.\n- `alignmentPeriodSeconds` is now included as part of `query` value.\n- `alignmentAligner` is now included as part of `query` value.\n- `GoogleApplicationCredentials`, `credentialsFromEnv`, `credentialsFromEnvFile` don't change.\n\n\nFor example, these scalers are equivalent:\n```yaml\n- type: gcp-stackdriver\n  metadata:\n    projectId: \"my-keda-project\"\n    filter: 'metric.type=\"pubsub.googleapis.com/topic/num_unacked_messages_by_region\" AND resource.type=\"pubsub_topic\" AND resource.label.topic_id=\"my-keda-topic\"'\n    targetValue: \"5\"\n    activationTargetValue: \"0\"\n    alignmentPeriodSeconds: \"60\"\n    alignmentAligner: max\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n```yaml\n- type: prometheus\n  metadata:\n    serverAddress: https://monitoring.googleapis.com/v1/projects/my-keda-project/location/global/prometheus\n    query: 'max(max_over_time({\"__name__\"=\"pubsub.googleapis.com/topic/num_unacked_messages_by_region\",\"monitored_resource\"=\"pubsub_topic\",\"topic_id\"=\"my-keda-topic\"}[1m]))'\n    threshold: \"5\"\n    activationThreshold: \"0\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n### Migrate Google Cloud Platform Pub/Sub\n\nFrom the current trigger spec:\n- `value ` and `activationValue` are replaced by `threshold` and `activationThreshold`.\n- `topicName` and `subscriptionName` are now included as part of `query` value.\n- `aggregation` is now included as part of `query` value.\n- `mode` is now included as part of `query` value.\n- `GoogleApplicationCredentials`, `credentialsFromEnv`, `credentialsFromEnvFile` don't change.\n\n\nFor example, these scalers are equivalent:\n```yaml\n- type: gcp-pubsub\n  metadata:\n    topicName: my-topic\n    mode: MessageSizes\n    aggregation: count\n    value: \"5\"\n    activationValue: \"0\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n```yaml\n- type: prometheus\n  metadata:\n    serverAddress: https://monitoring.googleapis.com/v1/projects/my-keda-project/location/global/prometheus\n    query: 'increase({\"__name__\"=\"pubsub.googleapis.com:topic_message_sizes_count\",\"monitored_resource\"=\"pubsub_topic\",\"topic_id\"=\"my-topic\"}[2m])'\n    threshold: \"5\"\n    activationThreshold: \"0\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\nKEDA maintainers.\n"
  },
  {
    "path": "content/blog/_index.md",
    "content": "+++\ntitle = \"The KEDA Blog\"\ndescription = \"Updates, tutorials, and more\"\n+++\n"
  },
  {
    "path": "content/community.md",
    "content": "+++\ntitle = \"Community\"\ndescription = \"How you can get involved with the KEDA ecosystem\"\n+++\n\n## Get Involved\n\n{{< include \"get-involved.md\" >}}\n\n## End-Users\n\n A variety of users are autoscaling applications with KEDA:\n\n{{< user-icons >}}\n\n## Partners\n\n KEDA is community-supported and built by our community, including the following companies:\n\n{{< partners-icons >}}\n\n## Supported by\n\nKEDA community is supported by the following companies that provide their services for free:\n\n{{< supportedby-icons >}}\n"
  },
  {
    "path": "content/docs/1.4/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/1.4/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates two custom resources:\n\n1. `scaledobjects.keda.k8s.io`\n1. `triggerauthentications.keda.k8s.io`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a deployment or job for scaling.  The `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes deployment.  A `ScaledObject` may also reference a `TriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/1.4/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use credentials or delegate authentication with `TriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/1.4/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `containerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam # Optional. Default: none\n  secretTargetRef: # Optional.\n  - parameter: {scaledObject-parameter-name} # Required.\n    name: {secret-name} # Required.\n    key: {secret-key-name} # Required.\n  env: # Optional.\n  - parameter: {scaledObject-parameter-name} # Required.\n    name: {env-name} # Required.\n    containerName: {container-name} # Optional. Default: scaleTargetRef.containerName of ScaledObject\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv: # Optional.\n  - parameter: region # Required - Defined by the scale trigger\n    name: my-env-var # Required.\n    containerName: my-container # Optional. Default: scaleTargetRef.containerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef: # Optional.\n  - parameter: connectionString # Required - Defined by the scale trigger\n    name: my-keda-secret-entity # Required.\n    key: azure-storage-connectionstring # Required.\n```\n\n**Assumptions:** `namespace` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise.\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | aws-eks | aws-kiam # Optional. Default: none\n```\n\n#### Azure Pod Identity\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which let's you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure # Optional. Default: false\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set aadPodIdentity={your-label-name}`.\n\n#### AWS EKS Pod Identity Webhook\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: false\n```\n\n#### AWS Kiam Pod Identity\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: false\n```\n"
  },
  {
    "path": "content/docs/1.4/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interface:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#4-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#5-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates replicaCount based on metric value and target value.\n\n### External Scaler GRPC interface\n\nKEDA comes with an external scaler [`external`](../scalers/external.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n\nFew things to notice:\n\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    deploymentName: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/1.4/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments\"\nweight = 200\n+++\n\n## Overview\n\nDeployments are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your deployment out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a deployment.  Each replica of a deployment is actively pulling items from the event source.  With KEDA and scaling deployments you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    deploymentName: {deployment-name} # must be in the same namespace as the ScaledObject\n    containerName: {container-name}  #Optional. Default: deployment.spec.template.spec.containers[0]\n  pollingInterval: 30  # Optional. Default: 30 seconds\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 100 # Optional. Default: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\nYou can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    deploymentName: {deployment-name} # must be in the same namespace\n    containerName: {container-name}  #Optional. Default: deployment.spec.template.spec.containers[0]\n```\n\nThe name of the deployment this scaledObject is for. This is the deployment KEDA will scale up and setup an HPA for based on the triggers defined in `triggers:`. Make sure to include the deployment name in the label as well, otherwise the metrics provider will not be able to query the metrics for the scaled object and 1-n scale will be broken.\n\n**Assumptions:** `deploymentName` is in the same namespace as the scaledObject.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the deployment up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the deployment back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment`, KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n```yaml\n  minReplicaCount: 0   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the deployment down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given deployment.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/1.4/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.4.0/pkg/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30  # Optional. Default: 30 seconds\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 100 # Optional. Default: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n"
  },
  {
    "path": "content/docs/1.4/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/1.4/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 2**\n\n    ```sh\n    helm install keda kedacore/keda  --version 1.4.2 --namespace keda --create-namespace\n    ```\n\n    **Helm 3**\n\n    ```sh\n    kubectl create namespace keda\n    helm install keda kedacore/keda --version 1.4.2 --namespace keda\n    ```\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster you can run one of the following:\n\n**Using Helm 3**\n\n```sh\nhelm uninstall -n keda keda\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\n```\n\n**Using Helm 2**\n\n```sh\nhelm delete --purge keda\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.4.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator\n2. Create namespace `keda`\n3. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:**Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\nWe provide sample YAML declarations which includes our CRD in the released zip and tar.gz package files which are available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nDownload the zip or tar.gz file, unpack it, enter the unpacked folder and just run the following commands.\n\n```sh\nkubectl apply -f ./crds\nkubectl apply -f ./\n```\n\nYou can also find the same YAML declarations in our `/deploy` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda && git checkout tags/v1.4.1\n\nkubectl apply -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl apply -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\nkubectl apply -f deploy/\n```\n\n### Uninstall\n\nYou would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nkubectl delete -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl delete -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\nkubectl delete -f deploy/\n```\n"
  },
  {
    "path": "content/docs/1.4/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq >}}\n"
  },
  {
    "path": "content/docs/1.4/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/1.4/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    # brokerList: kafka.svc:9092 - deprecated\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n```\n\n**Parameter list:**\n\n- `brokerList` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap (DEPRECATED).\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Topic on which processing the offset lag.\n- `lagThreshold` - How much the stream is lagging on the current consumer group. Default is 10. Optional.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing authMode, username, password. If your kafka cluster does not have sasl authentication turned on, you will not need to pay attention to it.\n\n**Credential based authentication:**\n\n- `authMode` - Kafka sasl auth mode. (Values: `none`, `sasl_plaintext`, `sasl_ssl`, `sasl_ssl_plain`, `sasl_scram_sha256`, `sasl_scram_sha512`. Default: `none`, Optional)\n- `username` - (Optional)\n- `password` - (Optional)\n- `ca` - Certificate authority file for TLS client authentication `sasl_ssl`. (Optional)\n- `cert` - Certificate for client authentication `sasl_ssl`. (Optional)\n- `key` - Key for client authentication with `sasl_ssl`. Optional)\n\n\n### Example\n\nYour kafka cluster no sasl auth:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n```\n\nYour kafka cluster turn on sasl auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  authMode: \"sasl_plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authMode\n    name: keda-kafka-secrets\n    key: authMode\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name\n    dimensionName: QueueName\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyID: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKey: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/1.4/concepts/authentication/).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for `ApproximateNumberOfMessages` in the SQS Queue. (Default: `5`, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\nnotice = \"As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connection: EVENTHUB_CONNECTIONSTRING_ENV_NAME # Connection string for Event Hub namespace appended with \"EntityPath=<event_hub_name>\"\n    storageConnection: STORAGE_CONNECTIONSTRING_ENV_NAME # Connection string for account used to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n    consumerGroup: $Default # Optional. Consumer group of event hub consumer. Default: $Default\n    unprocessedEventThreshold: '64' # Optional. Target number of unprocessed events across all partitions in Event Hub for HPA. Default: 64 events.\n    blobContainer: 'name_of_container' # Optional. Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function.\n```\n\nThe `connection` value is the name of the environment variable your deployment uses to get the Event Hub connection string which is appended with the Event Hub name using Entity Path variable. `storageConnection` is the name of the environment variable your deployment uses to get the Storage connection string.\n\nEnvironment variables are usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      connection: EventHub\n      storageConnection: AzureWebJobsStorage\n      # Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: CLIENT_ID_ENV_NAME\n    activeDirectoryClientPassword: CLIENT_PASSWORD_ENV_NAME\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource. The format is `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Tenant id for the Azure resource. Used for authentication.\n- `subscriptionId` - Subscription id for the Azure resource. Used for determining the full resource URI.\n- `resourceGroupName` - Resource group for the Azure resource.\n- `metricName` - Name of the Azure Monitor metric. Must be an officially supported metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Filter to define a more specific part of the resource. You can filter by supported dimensions of the metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Aggregation interval of the metric. Reported in the format `\"mm:hh:ss\"`. (Default: `\"0:5:0\"`, Optional)\n- `metricAggregationType` - Aggregation method of the Azure monitor metric. Some possible values include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). No default.\n- `targetValue` - Target value for the Azure metric to use in the HPA.\n- `activeDirectoryClientId` - Name of the environment variable that contains the active directory client id. Should have the RBAC role of `Monitoring Reader`.\n- `activeDirectoryClientPassword` - Name of the environment variable that contains the active directory client password. Should have the RBAC role of `Monitoring Reader`.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Active Directory client id.\n- `activeDirectoryClientPassword` - Active Directory client password.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\n  labels:\n    app: azure-monitor-example\nspec:\n  scaleTargetRef:\n    deploymentName: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: kube_pod_status_ready\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connection: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    queueLength: \"5\" # Optional. Subscription length target for HPA. Default: 5 messages\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connection` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `queueLength` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by delete/move the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob # Required: Name of Azure Blob Storage container\n    blobCount: '5' # Optional. Amount of blobs to scale out on. Default: 5 blobs\n    connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Optional if TriggerAuthentication defined with pod identity or connection string authentication.\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"/\"\n```\n\nThe `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: functionsqueue\n    queueLength: '5' # Optional. Queue length target for HPA. Default: 5 messages\n    connection: STORAGE_CONNECTIONSTRING_ENV_NAME\n```\n\nThe `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Required: connection OR authenticationRef that defines connection\n      connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: redis-external-scaler-service:8080\n    address: REDIS_HOST # Required host:port format\n    password: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n```\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    deploymentName: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentials` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    deploymentName: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Dimension name of the metric.\n- `dimensionValue` - Dimension value of the metric.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Min value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric. Equivalent to the earliest start time of the end time. (Default: `300`, Optional)\n- `metricFilter` - Aggregation method of the metric. (Values: `max`, `min`, `average`, `sum`, `variance`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric. (Default: `300`, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565 # Address of the gRPC liiklus API endpoint\n    group: my-group         # Make sure that this consumer group name is the same one as the one that is consuming topics\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"      # default 10, the target lag for HPA\n    groupVersion: 1         # default 0, the groupVersion to consider when looking at messages. See https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java\n```\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n- `connectionString` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `username` - Used to access MySQL database.\n- `password` - Used for the given user, this should be blank (no password) or point to an environment variable with the password.\n- `host` - Host of the database.\n- `port` - Port of the database.\n- `dbName` - As name of the database.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `connection` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    deploymentName: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\" # Location of the Nats Streaming monitoring endpoint\n    queueGroup: \"grp1\" # Queue group name of the subscribers\n    durableName: \"ImDurable\" # Must identify the durability name used by the subscribers\n    subject: \"Test\" # Name of channel\n    lagThreshold: \"10\" # Configures the TargetAverageValue on the Horizontal Pod Autoscaler (HPA)).\n```\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    deploymentName: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connection` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `password:` - Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connection: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    password: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: postgresql\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    deploymentName: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connection: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    threshold: '100'\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n```\n\nThe `serverAddress` indicates where Prometheus is running which contains the configured metric defined in `metricName` or `query`. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: RabbitMqHost\n    queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages\n    queueName: testqueue\n    includeUnacked: 'true' # Optional, use unacked + ready messages count\n    apiHost: RabbitApiHost # Optional HTTP management API endpoint\n```\n\nThe `host` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.  The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost`\n\n`apiHost` has the similar format but for HTTP API endpoint, like `https://guest:password@localhost:443/vhostname`. Note it has optional vhost name after the host slash which will be used to scope API request.\n\nBy default, `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages.\nIf `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\nAMQP protocol:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      # Required\n      host: RabbitMqHost # references a value of format amqp://guest:password@localhost:5672/vhost\n      queueName: testqueue\n      queueLength: \"20\"\n```\n\nHTTP protocol:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      includeUnacked: \"true\"\n      # Required\n      apiHost: RabbitApiHost # references a value of format https://guest:password@localhost:443/vhostname\n      queueName: testqueue\n      queueLength: \"20\"\n```\n"
  },
  {
    "path": "content/docs/1.4/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: REDIS_HOST # Required host:port format\n    password: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n```\n\nThe `address` field in the spec holds the host and port of the redis server. This could be an external redis server or one running in the kubernetes cluster.\n\nAs an alternative to the `address` field the user can specify `host` and `port` parameters.\n\nProvide the `password` field if the redis server requires a password. Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n\nThe `listName` parameter in the spec points to the Redis List that you want to monitor. The `listLength` parameter defines the average target value for the Horizontal Pod Autoscaler (HPA).\n\nThe `enableTLS` parameter if set to true allow a connection to a redis queue using tls, the default value for this parameter is false.\n\nThe `databaseIndex` parameter let the user select the redis database to use. If not specified, the default value is 0\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `password` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    deploymentName: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: REDIS_ADDRESS\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/1.4/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/1.5/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/1.5/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates two custom resources:\n\n1. `scaledobjects.keda.k8s.io`\n1. `triggerauthentications.keda.k8s.io`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a deployment or job for scaling.  The `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes deployment.  A `ScaledObject` may also reference a `TriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/1.5/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use credentials or delegate authentication with `TriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/1.5/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `containerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam # Optional. Default: none\n  secretTargetRef: # Optional.\n  - parameter: {scaledObject-parameter-name} # Required.\n    name: {secret-name} # Required.\n    key: {secret-key-name} # Required.\n  env: # Optional.\n  - parameter: {scaledObject-parameter-name} # Required.\n    name: {env-name} # Required.\n    containerName: {container-name} # Optional. Default: scaleTargetRef.containerName of ScaledObject\n  hashiCorpVault: # Optional.\n    address: {hashicorp-vault-address} # Required.\n    authentication: token | kubernetes # Required.\n    role: {hashicorp-vault-role} # Optional.\n    mount: {hashicorp-vault-mount} # Optional.\n    credential: # Optional.\n      token: {hashicorp-vault-token} # Optional.\n      serviceAccount: {path-to-service-account-file} # Optional.\n    secrets: # Required.\n    - parameter: {scaledObject-parameter-name} # Required.\n      key: {hashicorp-vault-secret-key-name} # Required.\n      path: {hashicorp-vault-secret-path} # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv: # Optional.\n  - parameter: region # Required - Defined by the scale trigger\n    name: my-env-var # Required.\n    containerName: my-container # Optional. Default: scaleTargetRef.containerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef: # Optional.\n  - parameter: connectionString # Required - Defined by the scale trigger\n    name: my-keda-secret-entity # Required.\n    key: azure-storage-connectionstring # Required.\n```\n\n**Assumptions:** `namespace` is in the same deployment as the configured `scaleTargetRef.deploymentName` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n\n```yaml\nhashiCorpVault: # Optional.\n  address: {hashicorp-vault-address} # Required.\n  authentication: token | kubernetes # Required.\n  role: {hashicorp-vault-role} # Optional.\n  mount: {hashicorp-vault-mount} # Optional.\n  credential: # Optional.\n    token: {hashicorp-vault-token} # Optional.\n    serviceAccount: {path-to-service-account-file} # Optional.\n  secrets: # Required.\n  - parameter: {scaledObject-parameter-name} # Required.\n    key: {hashicorp-vault-secret-key-name} # Required.\n    path: {hashicorp-vault-secret-path} # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | aws-eks | aws-kiam # Optional. Default: none\n```\n\n#### Azure Pod Identity\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which let's you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure # Optional. Default: false\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set aadPodIdentity={your-label-name}`.\n\n#### AWS EKS Pod Identity Webhook\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: false\n```\n\n#### AWS Kiam Pod Identity\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: false\n```\n"
  },
  {
    "path": "content/docs/1.5/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interface:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#4-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#5-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates replicaCount based on metric value and target value.\n\n### External Scaler GRPC interface\n\nKEDA comes with an external scaler [`external`](../scalers/external.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n\nFew things to notice:\n\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    deploymentName: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/1.5/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments\"\nweight = 200\n+++\n\n## Overview\n\nDeployments are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your deployment out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a deployment.  Each replica of a deployment is actively pulling items from the event source.  With KEDA and scaling deployments you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    deploymentName: {deployment-name} # must be in the same namespace as the ScaledObject\n    containerName: {container-name}  #Optional. Default: deployment.spec.template.spec.containers[0]\n  pollingInterval: 30  # Optional. Default: 30 seconds\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 100 # Optional. Default: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\nYou can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    deploymentName: {deployment-name} # must be in the same namespace\n    containerName: {container-name}  #Optional. Default: deployment.spec.template.spec.containers[0]\n```\n\nThe name of the deployment this scaledObject is for. This is the deployment KEDA will scale up and setup an HPA for based on the triggers defined in `triggers:`. Make sure to include the deployment name in the label as well, otherwise the metrics provider will not be able to query the metrics for the scaled object and 1-n scale will be broken.\n\n**Assumptions:** `deploymentName` is in the same namespace as the scaledObject.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the deployment up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the deployment back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment`, KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n\n```yaml\n  minReplicaCount: 0   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the deployment down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the deployment to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the deployment it will respect the value set there.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given deployment.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/1.5/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v1.5.0/pkg/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1 # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1 # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600 # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6 # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job/)\n      \n  pollingInterval: 30  # Optional. Default: 30 seconds\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 100 # Optional. Default: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n"
  },
  {
    "path": "content/docs/1.5/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/1.5/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 2**\n\n    ```sh\n    helm install keda kedacore/keda  --version 1.5.0 --namespace keda --create-namespace\n    ```\n\n    **Helm 3**\n\n    ```sh\n    kubectl create namespace keda\n    helm install keda kedacore/keda --version 1.5.0 --namespace keda\n    ```\n\n> 💡 When using Helm 3.x, make sure to manually install the CRDs since Helm does not update nor add new CRDs.\n> Learn more about it on [kedacore/charts #139](https://github.com/kedacore/charts/issues/139).\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster you can run one of the following:\n\n**Using Helm 3**\n\n```sh\nhelm uninstall -n keda keda\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\n```\n\n**Using Helm 2**\n\n```sh\nhelm delete --purge keda\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v1.5.0/deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator\n2. Create namespace `keda`\n3. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:**Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\nWe provide sample YAML declarations which includes our CRD in the released zip and tar.gz package files which are available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nDownload the zip or tar.gz file, unpack it, enter the unpacked folder and just run the following commands.\n\n```sh\nkubectl apply -f ./crds\nkubectl apply -f ./\n```\n\nYou can also find the same YAML declarations in our `/deploy` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda && git checkout tags/v1.5.0\n\nkubectl apply -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl apply -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\nkubectl apply -f deploy/\n```\n\n### Uninstall\n\nYou would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nkubectl delete -f deploy/crds/keda.k8s.io_scaledobjects_crd.yaml\nkubectl delete -f deploy/crds/keda.k8s.io_triggerauthentications_crd.yaml\nkubectl delete -f deploy/\n```\n"
  },
  {
    "path": "content/docs/1.5/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq >}}\n"
  },
  {
    "path": "content/docs/1.5/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/1.5/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    # brokerList: kafka.svc:9092 - deprecated\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n```\n\n**Parameter list:**\n\n- `brokerList` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap (DEPRECATED).\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Topic on which processing the offset lag.\n- `lagThreshold` - How much the stream is lagging on the current consumer group. Default is 10. Optional.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing authMode, username, password. If your kafka cluster does not have sasl authentication turned on, you will not need to pay attention to it.\n\n**Credential based authentication:**\n\n- `authMode` - Kafka sasl auth mode. (Values: `none`, `sasl_plaintext`, `sasl_ssl`, `sasl_ssl_plain`, `sasl_scram_sha256`, `sasl_scram_sha512`. Default: `none`, Optional)\n- `username` - (Optional)\n- `password` - (Optional)\n- `ca` - Certificate authority file for TLS client authentication `sasl_ssl`. (Optional)\n- `cert` - Certificate for client authentication `sasl_ssl`. (Optional)\n- `key` - Key for client authentication with `sasl_ssl`. Optional)\n\n\n### Example\n\nYour kafka cluster no sasl auth:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n```\n\nYour kafka cluster turn on sasl auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  authMode: \"sasl_plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authMode\n    name: keda-kafka-secrets\n    key: authMode\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - \"hostname:port\" to connect to ActiveMQ Artemis management endpoint.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address name of the broker.\n- `queueLength` - How much messages are in the queue. (Default: `10`, Optional.)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\n  labels:\n    deploymentName: kedartemis-consumer\nspec:\n  scaleTargetRef:\n    deploymentName: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/1.5/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name\n    dimensionName: QueueName\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyID: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKey: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/1.5/concepts/authentication/).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for `ApproximateNumberOfMessages` in the SQS Queue. (Default: `5`, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\nnotice = \"As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connection: EVENTHUB_CONNECTIONSTRING_ENV_NAME # Connection string for Event Hub namespace appended with \"EntityPath=<event_hub_name>\"\n    storageConnection: STORAGE_CONNECTIONSTRING_ENV_NAME # Connection string for account used to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n    consumerGroup: $Default # Optional. Consumer group of event hub consumer. Default: $Default\n    unprocessedEventThreshold: '64' # Optional. Target number of unprocessed events across all partitions in Event Hub for HPA. Default: 64 events.\n    blobContainer: 'name_of_container' # Optional. Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function.\n```\n\nThe `connection` value is the name of the environment variable your deployment uses to get the Event Hub connection string which is appended with the Event Hub name using Entity Path variable. `storageConnection` is the name of the environment variable your deployment uses to get the Storage connection string.\n\nEnvironment variables are usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      connection: EventHub\n      storageConnection: AzureWebJobsStorage\n      # Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: CLIENT_ID_ENV_NAME\n    activeDirectoryClientPassword: CLIENT_PASSWORD_ENV_NAME\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource. The format is `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Tenant id for the Azure resource. Used for authentication.\n- `subscriptionId` - Subscription id for the Azure resource. Used for determining the full resource URI.\n- `resourceGroupName` - Resource group for the Azure resource.\n- `metricName` - Name of the Azure Monitor metric. Must be an officially supported metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Filter to define a more specific part of the resource. You can filter by supported dimensions of the metric found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Aggregation interval of the metric. Reported in the format `\"mm:hh:ss\"`. (Default: `\"0:5:0\"`, Optional)\n- `metricAggregationType` - Aggregation method of the Azure monitor metric. Some possible values include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). No default.\n- `targetValue` - Target value for the Azure metric to use in the HPA.\n- `activeDirectoryClientId` - Name of the environment variable that contains the active directory client id. Should have the RBAC role of `Monitoring Reader`.\n- `activeDirectoryClientPassword` - Name of the environment variable that contains the active directory client password. Should have the RBAC role of `Monitoring Reader`.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Active Directory client id.\n- `activeDirectoryClientPassword` - Active Directory client password.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\n  labels:\n    app: azure-monitor-example\nspec:\n  scaleTargetRef:\n    deploymentName: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: kube_pod_status_ready\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connection: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    queueLength: \"5\" # Optional. Subscription length target for HPA. Default: 5 messages\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connection` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `queueLength` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by delete/move the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob # Required: Name of Azure Blob Storage container\n    blobCount: '5' # Optional. Amount of blobs to scale out on. Default: 5 blobs\n    connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Optional if TriggerAuthentication defined with pod identity or connection string authentication.\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"/\"\n```\n\nThe `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: functionsqueue\n    queueLength: '5' # Optional. Queue length target for HPA. Default: 5 messages\n    connection: STORAGE_CONNECTIONSTRING_ENV_NAME\n```\n\nThe `connection` value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Required: connection OR authenticationRef that defines connection\n      connection: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 30 * * * *       # Every hour on the 30th minute\n    end: 45 * * * *         # Every hour on the 45th minute\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found in: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones.\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled between the start and end of the cron schedule.\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 30 * * * *\n> end: 30 * * * *\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: my-deployment\n  triggers:\n  - type: cron\n    metadata:\n      timezone: Asia/Kolkata\n      start: 30 * * * *\n      end: 45 * * * *\n      desiredReplicas: \"10\"\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: redis-external-scaler-service:8080\n    address: REDIS_HOST # Required host:port format\n    password: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n```\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    deploymentName: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentials` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    deploymentName: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentials: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Dimension name of the metric.\n- `dimensionValue` - Dimension value of the metric.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Min value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric. Equivalent to the earliest start time of the end time. (Default: `300`, Optional)\n- `metricFilter` - Aggregation method of the metric. (Values: `max`, `min`, `average`, `sum`, `variance`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric. (Default: `300`, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\n  labels:\n    test: nginx-deployment\nspec:\n  scaleTargetRef:\n    deploymentName: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565 # Address of the gRPC liiklus API endpoint\n    group: my-group         # Make sure that this consumer group name is the same one as the one that is consuming topics\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"      # default 10, the target lag for HPA\n    groupVersion: 1         # default 0, the groupVersion to consider when looking at messages. See https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java\n```\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n- `connectionString` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `username` - Used to access MySQL database.\n- `password` - Used for the given user, this should be blank (no password) or point to an environment variable with the password.\n- `host` - Host of the database.\n- `port` - Port of the database.\n- `dbName` - As name of the database.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `connection` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    deploymentName: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\" # Location of the Nats Streaming monitoring endpoint\n    queueGroup: \"grp1\" # Queue group name of the subscribers\n    durableName: \"ImDurable\" # Must identify the durability name used by the subscribers\n    subject: \"Test\" # Name of channel\n    lagThreshold: \"10\" # Configures the TargetAverageValue on the Horizontal Pod Autoscaler (HPA)).\n```\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    deploymentName: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connection` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `password:` - Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connection: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    password: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: postgresql\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    deploymentName: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connection: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    threshold: '100'\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n```\n\nThe `serverAddress` indicates where Prometheus is running which contains the configured metric defined in `metricName` or `query`. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: RabbitMqHost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages\n    queueName: testqueue\n    includeUnacked: 'true' # Optional, use unacked + ready messages count\n    apiHost: RabbitApiHost # Optional. Represents the HTTP management API endpoint. If not specified, it must be done by using TriggerAuthentication.\n  authenticationRef:\n    name: keda-trigger-auth-rabbitmq-conn\n```\n\n**Parameter list:**\n\n- `host` - Value is the name of the environment variable your deployment uses to get the connection string. This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.  The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost`.\n- `queueName` - Name of the queue to read message from.\n- `queueLength` - Queue length target for HPA. (Default: `20`, Optional)\n- `includeUnacked` - By default, `includeUnacked` is `false` in this case scaler uses AMQP protocol, requires `host` and only counts messages in the queue and ignores unacked messages. If `includeUnacked` is `true` then `host` is not required but `apiHost` is required in this case scaler uses HTTP management API and counts messages in the queue + unacked messages count. `host` or `apiHost` value comes from authentication trigger. (Optional)\n- `apiHost` - It has similar format as of `host` but for HTTP API endpoint, like https://guest:password@localhost:443/vhostname.\n\nNote `host` and `apiHost` both have an optional vhost name after the host slash which will be used to scope API request.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- `host` - AMQP URI connection string, like `amqp://guest:password@localhost:5672/vhost`.\n- `apiHost` - HTTP API endpoint, like `https://guest:password@localhost:443/vhostname`.\n\n### Example\n\nAMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: testqueue\n      queueLength: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\nHTTP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  apiHost: <HTTP API endpoint> # base64 encoded value of format https://guest:password@localhost:443/vhostname\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiHost\n      name: keda-rabbitmq-secret\n      key: apiHost\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    deploymentName: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      includeUnacked: \"true\"\n      queueName: testqueue\n      queueLength: \"20\"\n    authenticationRef:\n      name: rabbitmq-consumer-trigger\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: REDIS_HOST # Required host:port format\n    password: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n```\n\nThe `address` field in the spec holds the host and port of the redis server. This could be an external redis server or one running in the kubernetes cluster.\n\nAs an alternative to the `address` field the user can specify `host` and `port` parameters.\n\nProvide the `password` field if the redis server requires a password. Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n\nThe `listName` parameter in the spec points to the Redis List that you want to monitor. The `listLength` parameter defines the average target value for the Horizontal Pod Autoscaler (HPA).\n\nThe `enableTLS` parameter if set to true allow a connection to a redis queue using tls, the default value for this parameter is false.\n\nThe `databaseIndex` parameter let the user select the redis database to use. If not specified, the default value is 0\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `password` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    deploymentName: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: REDIS_ADDRESS\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/1.5/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: REDIS_SERVER # Required if host and port are not provided. Format - host:port\n    host: REDIS_HOST # Required if address is not provided\n    port: REDIS_PORT # Required if address is not provided and host has been provided\n    password: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n```\n\n**Parameter list:**\n\n- `address` - Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n   - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - Name of the environment variable your deployment uses to get the Redis server host.\n    - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n> It is not required if `address` has been provided..\n\n- `port` - Name of the environment variable your deployment uses to get the Redis server port.\n   - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n> It is only to be used along with the `host` attribute and not required if `address` has been provided.\n\n- `password` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n   - This is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\n- `stream` - Name of the Redis Stream.\n\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\n  labels:\n    deploymentName: redis-streams-consumer\nspec:\n  scaleTargetRef:\n    deploymentName: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: REDIS_HOST\n        password: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\n  labels:\n    deploymentName: redis-streams-consumer\nspec:\n  scaleTargetRef:\n    deploymentName: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: REDIS_HOST\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/1.5/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.0/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.0/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.0/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates three custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.  \n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource. \n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.  \n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.0/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use credentials or delegate authentication with `TriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.0/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam  # Optional. Default: none\n  secretTargetRef:                                    # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {secret-name}                               # Required.\n    key: {secret-key-name}                            # Required.\n  env:                                                # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {env-name}                                  # Required.\n    containerName: {container-name}                   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                     # Optional.\n    address: {hashicorp-vault-address}                # Required.\n    authentication: token | kubernetes                # Required.\n    role: {hashicorp-vault-role}                      # Optional.\n    mount: {hashicorp-vault-mount}                    # Optional.\n    credential:                                       # Optional.\n      token: {hashicorp-vault-token}                  # Optional.\n      serviceAccount: {path-to-service-account-file}  # Optional.\n    secrets:                                          # Required.\n    - parameter: {scaledObject-parameter-name}        # Required.\n      key: {hashicorp-vault-secret-key-name}           # Required.\n      path: {hashicorp-vault-secret-path}              # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}"
  },
  {
    "path": "content/docs/2.0/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interfaces:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nFew things to notice:\n\n- Lack of `Close` method as the GRPC connection defines the lifetime of the scaler\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\nFor `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.0/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/v2.0.0/api/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval: 30                                # Optional. Default: 30 seconds\n  cooldownPeriod:  300                               # Optional. Default: 300 seconds\n  minReplicaCount: 0                                 # Optional. Default: 0\n  maxReplicaCount: 100                               # Optional. Default: 100\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n```yaml\n  minReplicaCount: 0   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource.\n\n---\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.0/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/v2.0.0/api/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcome of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of the length of the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) {\n>\t\t\tpendingJobs++\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n  return maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n"
  },
  {
    "path": "content/docs/2.0/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.0/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n- [MicroK8s addon](#microk8s)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda  --version 2.0.0 --namespace keda --create-namespace\n    ```\n\n> 💡 Make sure to manually install the CRDs since Helm does not update nor add new CRDs.\n> Learn more about it on [kedacore/charts #139](https://github.com/kedacore/charts/issues/139).\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster you can run one of the following:\n\n**Using Helm 3**\n\n```sh\nhelm uninstall -n keda keda\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.0.0/config/crd/bases/keda.sh_scaledobjects.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.0.0/config/crd/bases/keda.sh_scaledjobs.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.0.0/config/crd/bases/keda.sh_triggerauthentications.yaml\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.0.0`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.0.0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.0.0 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.0.0`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.0.0/keda-2.0.0.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.0.0.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.0.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```"
  },
  {
    "path": "content/docs/2.0/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.0/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.0/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for it's Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.0/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n"
  },
  {
    "path": "content/docs/2.0/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.0 has been tested on Kubernetes v1.16.0 or above.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                              |\n| ------ | -------------------------------------------- | ---------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms, except for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud                       |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 1                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.This is only supported as of KEDA v2.6 if you are using our Helm chart.                                                                                    |\n"
  },
  {
    "path": "content/docs/2.0/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.0/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.0/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag.\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.0/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name\n    dimensionName: QueueName\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.0/concepts/authentication/).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets       # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual `ApproximateNumberOfMessages` in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\nnotice = \"As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of event hub consumer. (Default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function.\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      connectionFromEnv: EventHub\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nA data types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.0/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"mm:hh:ss\"` (default: `\"0:5:0\"` which is 5 minutes)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. Optional. Required when `TriggerAuthentication` is not provided.\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: kube_pod_status_ready\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by delete/move the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.0/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Password Authentication:**\n\n- `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager.\n- `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional,\nbecause many application implements basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication. This is a required field.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric must be json number type. The value is casted to **integer**.\n\nHere is an example of a  metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a  metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a  metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment\n variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: postgresql\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Metric name to use.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: amqp # Specifies protocol to use, either amqp or http. Default value is amqp.\n    queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages\n    queueName: testqueue\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `amqp://<host>:<port>/<vhost>`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20. Optional.\n- `protocol` - Protocol to be used for communication. Either `http` or `amqp`. It should correspond with the `host` value.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The connection string of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      queueLength: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      queueLength: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.0/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.0/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.1/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.1/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.1/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.1/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam  # Optional. Default: none\n  secretTargetRef:                                    # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {secret-name}                               # Required.\n    key: {secret-key-name}                            # Required.\n  env:                                                # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {env-name}                                  # Required.\n    containerName: {container-name}                   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                     # Optional.\n    address: {hashicorp-vault-address}                # Required.\n    authentication: token | kubernetes                # Required.\n    role: {hashicorp-vault-role}                      # Optional.\n    mount: {hashicorp-vault-mount}                    # Optional.\n    credential:                                       # Optional.\n      token: {hashicorp-vault-token}                  # Optional.\n      serviceAccount: {path-to-service-account-file}  # Optional.\n    secrets:                                          # Required.\n    - parameter: {scaledObject-parameter-name}        # Required.\n      key: {hashicorp-vault-secret-key-name}           # Required.\n      path: {hashicorp-vault-secret-path}              # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.1/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interfaces:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nFew things to notice:\n\n- Lack of `Close` method as the GRPC connection defines the lifetime of the scaler\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\nFor `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.1/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval: 30                                # Optional. Default: 30 seconds\n  cooldownPeriod:  300                               # Optional. Default: 300 seconds\n  minReplicaCount: 0                                 # Optional. Default: 0\n  maxReplicaCount: 100                               # Optional. Default: 100\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n```yaml\n  minReplicaCount: 0   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource.\n\n---\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.1/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) {\n>\t\t\tpendingJobs++\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n  return maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n"
  },
  {
    "path": "content/docs/2.1/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.1/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n- [MicroK8s addon](#microk8s)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    ```sh\n    helm install keda kedacore/keda  --version 2.1.0 --namespace keda --create-namespace\n    ```\n\n> 💡 Make sure to manually install the CRDs since Helm does not update nor add new CRDs.\n> Learn more about it on [kedacore/charts #139](https://github.com/kedacore/charts/issues/139).\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster you can run one of the following:\n\n```sh\nhelm uninstall -n keda keda\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_scaledobjects.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_scaledjobs.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_triggerauthentications.yaml\nkubectl delete -f https://raw.githubusercontent.com/kedacore/keda/v2.1.0/config/crd/bases/keda.sh_clustertriggerauthentications.yaml\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.1.0`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.1.0/keda-2.1.0.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.1.0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.1.0 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.1.0`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.1.0/keda-2.1.0.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.1.0.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.1.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```"
  },
  {
    "path": "content/docs/2.1/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.1/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.1/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.1/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n"
  },
  {
    "path": "content/docs/2.1/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.1 has been tested on Kubernetes v1.16.0 or above.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                              |\n| ------ | -------------------------------------------- | ---------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms, except for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud                       |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.This is only supported as of KEDA v2.6 if you are using our Helm chart.                                                                                    |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable to your desired timeout in milliseconds. For example, on Linux/Mac/Windows WSL2 operating systems, you'd use this command to set to 1 second:\n\n```shell\nexport KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAnd on Windows Powershell, you'd use this command:\n\n```shell\n$env:KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAll applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported.\n"
  },
  {
    "path": "content/docs/2.1/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.1/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.1/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag.\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.1/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName\n    dimensionName: QueueName\n    # Required: Dimension Value - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Metric Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.1/concepts/authentication/).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets       # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual `ApproximateNumberOfMessages` in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\nnotice = \"As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of event hub consumer. (Default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function.\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.1/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: kube_pod_status_ready\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.1/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Password Authentication:**\n\n- `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager.\n- `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric must be json number type. The value is casted to **integer**.\n\nHere is an example of a  metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a  metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a  metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server with database used.It would be written like this \"portnumber/dbname\"\n      port: \"27017/test\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server with the `dbName` separated by slash `/`.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `password` - Password for the configured user to login to MongoDB server.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment\n variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Required\n    containerName: my-container # Required\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs. This is needed due to Go URL parsing issues :sweat_smile:\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. It must contain the hostname, the Swift port, the API version and the account ID. The pattern is: `http://<host>:<swift_port>/<swift_version>/<account_id>`.\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.1/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Metric name to use.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    queueLength: '20' # Optional. Queue length target for HPA. Default: 20 messages\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `amqp://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20. Optional.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      queueLength: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      queueLength: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.1/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.1/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.10/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n\n> Note, that you must \"federate\" the Azure AD Managed Identity (that the TriggerAuthentication `podIdentity.identityId` points to) with the 'subject' of the KEDA Operator service account. This will be similar to `system:serviceaccount:keda:keda-operator`. \n> 📝 The service account for the target deployment is not used here.\n\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure | azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.10/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.10/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.10/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n"
  },
  {
    "path": "content/docs/2.10/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure | azure-workload                                    # Required.\n      identityId: <identity-id>                                           # Optional\n    vaultUri: {key-vault-address}                                         # Required.\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler.\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | azure-workload | aws-eks | aws-kiam  # Optional. Default: none\n  identityId: <identity-id>                                     # Optional. Only used by azure & azure-workload providers.\n```\n\n#### Azure Pod Identity\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n#### AWS EKS Pod Identity Webhook\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n\n#### AWS Kiam Pod Identity\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.10/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.10/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: ([Experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features)) Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics (Experimental)\"](#caching-metrics-experimental). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Caching Metrics (Experimental)\n\n This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. \n \n Enabling this feature can significantly reduce the load on the scaler service. \n \n This is an [experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features).\n \n This feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n```\n\nThe presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition.\n\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.10/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.10/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.10/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.10.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1.yaml\n# Without admission webhooks\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply -f keda-2.10.1.yaml\n# Without admission webhooks\nkubectl apply -f keda-2.10.1-core.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.10.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.10.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.10.1/keda-2.10.1-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.10.1.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.10.1-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.10.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.10/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.10/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD).\n- `keda_trigger_totals` - Total number of triggers per trigger type.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\n> 💡 **DEPRECATED:** Prometheus Metrics exposed from Metrics Server are deprecated, please consume metrics from KEDA Operator.\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.10/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.10/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.10/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n"
  },
  {
    "path": "content/docs/2.10/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP connection disable keep alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment     | Default Value | Affected reconciler           |\n| ------------------------------------- | -------------- | ------------- | ----------------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator       | 5             | ScaledObjectReconciler        |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator       | 1             | ScaledJobReconciler           |\n| KEDA_METRICS_CTRL_MAX_RECONCILES      | Metrics Server | 1             | MetricsScaledObjectReconciler |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.10/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.10/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.10/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nThe KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`).\n"
  },
  {
    "path": "content/docs/2.10/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.10/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.10/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.10/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    identityOwner: pod | operator # Optional. Default: pod\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`.\n\n- `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well.\n  - When set to `false` \"actual messages\" is equal to `ApproximateNumberOfMessages`. When set to `true` \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    clientSecret: t0p-s3cret  # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `clientSecret` - Password of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId. DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n###Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n      metricName: \"test_keyspace\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `metricName` - Name to assign to the metric. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n      metricName: \"global-metric\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.10/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n## Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n## Cases of unexpected metrics value in DataDog API response\n\n### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.10/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5.5\" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge\n    activationValue: \"10.5\" # Optional - Default is 0\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n`subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n\n- Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n- Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nYou can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`.\nThe mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`.\nThe `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```"
  },
  {
    "path": "content/docs/2.10/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n    authenticationRef:\n      name: personalAccessToken\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric, DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.10/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below)\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n**Azure Monitor managed service for Prometheus**\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload # use \"azure\" for pod identity and \"azure-workload\" for workload identity\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      metricName: http_requests_total\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`,`basic`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n      platformName: 'Linux' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.10/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    activationMessageCountTarget:       '100'\n    activationMessageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.10/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.11/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n> Note, that you must \"federate\" the Azure AD Managed Identity (that the TriggerAuthentication `podIdentity.identityId` points to) with the 'subject' of the KEDA Operator service account. This will be similar to `system:serviceaccount:keda:keda-operator`. \n> 📝 The service account for the target deployment is not used here.\n\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure | azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.11/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.11/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.11/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n"
  },
  {
    "path": "content/docs/2.11/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure | azure-workload                                    # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler.\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | azure-workload | aws-eks | aws-kiam  # Optional. Default: none\n  identityId: <identity-id>                                     # Optional. Only used by azure & azure-workload providers.\n```\n\n#### Azure Pod Identity\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n#### AWS EKS Pod Identity Webhook\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n\n#### AWS Kiam Pod Identity\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.11/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.11/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"      # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    autoscaling.keda.sh/paused-replicas: \"0\"                # Optional. Use to pause autoscaling of objects\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval.\n\nEnabling this feature can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n```\n\nThe presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition.\n\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transfer ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.11/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again.\n\nYou can enable this by adding the below annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nThe above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.11/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.11/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.11.2`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.11.2.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.11.2-core.yaml\n```\n\n> 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details.\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.11.2 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.11.2`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.11.2/keda-2.11.2-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.11.2.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.11.2-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.11.2 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.11/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.11/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD).\n- `keda_trigger_totals` - Total number of triggers per trigger type.\n- `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.11/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.11/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.11/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n"
  },
  {
    "path": "content/docs/2.11/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP connection disable keep alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.11/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.11/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (just an external metric):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query an specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.11/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nThe KEDA operator is responsible for generating certificates for all the services, this behaviour can be disabled removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`).\n"
  },
  {
    "path": "content/docs/2.11/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.11/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.11/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.11/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    identityOwner: pod | operator # Optional. Default: pod\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`.\n\n- `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well.\n  - When set to `false` \"actual messages\" is equal to `ApproximateNumberOfMessages`. When set to `true` \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    clientSecret: t0p-s3cret  # DEPRECATED, use TriggerAuthentication or clientSecretFromEnv\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `clientSecret` - Password of the Azure AD application. (DEPRECATED: This parameter is deprecated as of KEDA v2.11 and will be removed in version `2.13`)\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId. DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n###Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n      metricName: \"test_keyspace\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `metricName` - Name to assign to the metric. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n      metricName: \"global-metric\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.11/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n## Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n## Cases of unexpected metrics value in DataDog API response\n\n### Latest data point is unavailable\n\nBy default Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.11/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5.5\" # Optional - Default is 10\n    activationValue: \"10.5\" # Optional - Default is 0\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the camel case of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metric starts with `subscription/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric, DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` . (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\" # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.11/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n    metricName: backlog_process_count # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12. Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below)\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n**Azure Monitor managed service for Prometheus**\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\n**Google Managed for Prometheus:**\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version 2.12\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload # use \"azure\" for pod identity and \"azure-workload\" for workload identity\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      metricName: http_requests_total\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`,`basic`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    unsafeSsl: true\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue # DEPRECATED: This parameter is deprecated as of KEDA v2.10 and will be removed in version `2.12`. optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.11/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n      platformName: 'Linux' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.11/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.11/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.12/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n> Note, that you must \"federate\" the Azure AD Managed Identity (that the TriggerAuthentication `podIdentity.identityId` points to) with the 'subject' of the KEDA Operator service account. This will be similar to `system:serviceaccount:keda:keda-operator`. \n> 📝 The service account for the target deployment is not used here.\n\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure | azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.12/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.12/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.12/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.12/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure | azure-workload                                    # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler.\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | azure-workload | aws-eks | aws-kiam  # Optional. Default: none\n  identityId: <identity-id>                                     # Optional. Only used by azure & azure-workload providers.\n```\n\n#### Azure Pod Identity\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n#### AWS EKS Pod Identity Webhook\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n\n#### AWS Kiam Pod Identity\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.12/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.12/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"      # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    autoscaling.keda.sh/paused-replicas: \"0\"                # Optional. Use to pause autoscaling of objects\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n##### `scalingModifiers`\n\nThe `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n###### `scalingModifiers.target`\n\n`target` defines new target value to scale on for the composed metric.\n\n###### `scalingModifiers.activationTarget`\n\n`activationTarget` defines new [activation target value](./scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n###### `scalingModifiers.metricType`\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n###### `scalingModifiers.formula`\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](#scaling-modifiers-experimental) below.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval.\n\nEnabling this feature can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo enable/unpause autoscaling again, simply remove all paused annotations from the `ScaledObject` definition.\n\n\n### Scaling Modifiers (Experimental)\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"float(trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0)\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean)\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transfer ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.12/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again.\n\nYou can enable this by adding the below annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nThe above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.12/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.12/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\nTo deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.12.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.12.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.12.1-core.yaml\n```\n\n> 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details.\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.12.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.12.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.12.1/keda-2.12.1-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.12.1.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.12.1-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.12.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.12/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.12/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector using HTTP. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in|active (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.12/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD).\n- `keda_trigger_totals` - Total number of triggers per trigger type.\n- `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.12/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.12/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.12/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n"
  },
  {
    "path": "content/docs/2.12/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP connection disable keep alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.12/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.12/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (just an external metric):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.12/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`).\n"
  },
  {
    "path": "content/docs/2.12/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.12/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.12/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.12/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    identityOwner: pod | operator # Optional. Default: pod\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    clientSecret: t0p-s3cret  # DEPRECATED, use TriggerAuthentication or clientSecretFromEnv\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `clientSecret` - Password of the Azure AD application. (DEPRECATED: This parameter is deprecated as of KEDA v2.11 and will be removed in version `2.13`)\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n- \n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n###Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](./../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.12/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n## Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n## Cases of unexpected metrics value in DataDog API response\n\n### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.12/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform‎ Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5.5\" # Optional - Default is 10\n    activationValue: \"10.5\" # Optional - Default is 0\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the camel case of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metric starts with `subscription/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.12/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below)\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n**Azure Monitor managed service for Prometheus**\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\n**Google Managed for Prometheus:**\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload # use \"azure\" for pod identity and \"azure-workload\" for workload identity\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n```"
  },
  {
    "path": "content/docs/2.12/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    unsafeSsl: true\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.12/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n      platformName: 'Linux' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.12/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.12/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.13/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\n> ⚠️ **WARNING:** `aws-kiam` auth has been deprecated given [AWS KIAM is no longer maintained](https://github.com/uswitch/kiam/#-%EF%B8%8Fthis-project-is-now-being-abandoned-%EF%B8%8F-). As a result, [support for it will be removed from KEDA on v2.15](https://github.com/kedacore/keda/discussions/5342). We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication uses automatically both, doing a fallback from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html), you just need to add KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a a basic configuration for an IRSA role. The policy changes depend if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nThis is the easiest case and you just need to attach to KEDA's role the desired policy/policies, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\n> ⚠️ **WARNING:** [Azure AD Pod Identity was archived](https://github.com/Azure/aad-pod-identity#-announcement) and support for it will be removed from KEDA on v2.15. We strongly encourage the migration to [Azure Workload Identity](https://azure.github.io/azure-workload-identity).\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure | azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional.\n    serviceAccount: {path-to-service-account-file}            # Optional.\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.13/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.13/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.13/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.13/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure | azure-workload                                    # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | azure-workload | aws | aws-eks | aws-kiam  # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Pod Identity\n\n> [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5362)\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n\n#### AWS Kiam Pod Identity\n\n> [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5342)\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.13/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.13/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"      # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    autoscaling.keda.sh/paused-replicas: \"0\"                # Optional. Use to pause autoscaling of objects\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig:`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n##### `scalingModifiers`\n\nThe `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n###### `scalingModifiers.target`\n\n`target` defines new target value to scale on for the composed metric.\n\n###### `scalingModifiers.activationTarget`\n\n`activationTarget` defines new [activation target value](./scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n###### `scalingModifiers.metricType`\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n###### `scalingModifiers.formula`\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](#scaling-modifiers-experimental) below.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval.\n\nEnabling this feature can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo enable/unpause autoscaling again, simply remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can also set the annotation to `false` to unpause.\n\n\n### Scaling Modifiers (Experimental)\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transfer ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.13/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again.\n\nYou can enable this by adding the below annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nThe above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.13/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.13/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.24 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\nTo deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.13.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.13.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.13.1-core.yaml\n```\n\n> 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details.\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.13.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.13.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.13.1/keda-2.13.1-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.13.1.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.13.1-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.13.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.13/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.13/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector using HTTP. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n"
  },
  {
    "path": "content/docs/2.13/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD).\n- `keda_trigger_totals` - Total number of triggers per trigger type.\n- `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.13/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.13/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.13/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n"
  },
  {
    "path": "content/docs/2.13/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP connection disable keep alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.13/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | \n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    | \n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails |                                                                           |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails            |                                                                     |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch |                                                                    |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch |                                                                       |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob |                                                           |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob |                                                         |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source|                                                                       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1|                                         |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 |                                        |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1|                                                              |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0|                                                              |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob |                                                                                       |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added|                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted|                                                                                       |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added|                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted|                                                                                |\n\n\n## CloudEvent Support (Experimental)\n\n### Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  destination:\n    http:\n      uri: http://foo.bar\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n### Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n\n#### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n### Supported Event List\n| Event Type                                | Scenario Description                                                                                                                 | \n| ------------------------------------- |  --------------------------------------------------------------------------------------------------------------------------- | \n| `keda.scaledobject.ready.v1`                   | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1`             | If the check validation for a ScaledObject fails |      "
  },
  {
    "path": "content/docs/2.13/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (just an external metric):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.13/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`).\n"
  },
  {
    "path": "content/docs/2.13/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.13/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.13/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.13/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator \n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](./../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.13/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n## Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n## Cases of unexpected metrics value in DataDog API response\n\n### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.13/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```"
  },
  {
    "path": "content/docs/2.13/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform‎ Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    activationValue: \"10.5\" # Optional - Default is 0\n    # Either one of subscriptionName or topicName is required\n    subscriptionName: \"mysubscription\"\n    topicName: \"mytopic\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.13/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below)\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload # use \"azure\" for pod identity and \"azure-workload\" for workload identity\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.13/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    unsafeSsl: true\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.13/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n      platformName: 'Linux' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.13/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.13/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.14/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\n> ⚠️ **WARNING:** `aws-kiam` auth has been deprecated given [AWS KIAM is no longer maintained](https://github.com/uswitch/kiam/#-%EF%B8%8Fthis-project-is-now-being-abandoned-%EF%B8%8F-). As a result, [support for it will be removed from KEDA on v2.15](https://github.com/kedacore/keda/discussions/5342). We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication uses automatically both, doing a fallback from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html), you just need to add KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a a basic configuration for an IRSA role. The policy changes depend if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nThis is the easiest case and you just need to attach to KEDA's role the desired policy/policies, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\n> ⚠️ **WARNING:** [Azure AD Pod Identity was archived](https://github.com/Azure/aad-pod-identity#-announcement) and support for it will be removed from KEDA on v2.15. We strongly encourage the migration to [Azure Workload Identity](https://azure.github.io/azure-workload-identity).\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure | azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional.\n    serviceAccount: {path-to-service-account-file}            # Optional.\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.14/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.14/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.14/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.14/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure | azure-workload                                    # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | azure-workload | aws | aws-eks | aws-kiam  # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Pod Identity\n\n> [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5362)\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n\n#### AWS Kiam Pod Identity\n\n> [DEPRECATED: This will be removed in KEDA v2.15](https://github.com/kedacore/keda/discussions/5342)\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.14/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.14/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`.\n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:        30                                # Optional. Default: 30 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  cooldownPeriod:         300                               # Optional. Default: 300 seconds\n  idleReplicaCount:       0                                 # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:        1                                 # Optional. Default: 0\n  maxReplicaCount:        100                               # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`. By default, this is 0 seconds, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig:`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n##### `scalingModifiers`\n\nThe `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n###### `scalingModifiers.target`\n\n`target` defines new target value to scale on for the composed metric.\n\n###### `scalingModifiers.activationTarget`\n\n`activationTarget` defines new [activation target value](./scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n###### `scalingModifiers.metricType`\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n###### `scalingModifiers.formula`\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](#scaling-modifiers-experimental) below.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval.\n\nEnabling this feature can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo enable/unpause autoscaling again, simply remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can also set the annotation to `false` to unpause.\n\n\n### Scaling Modifiers (Experimental)\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transfer ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disable validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.14/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is a great alternative to deleting the resource, because we do not want to touch the applications themselves but simply remove the instances it is running from an operational perspective. Once everything is good to go, we can enable it to scale again.\n\nYou can enable this by adding the below annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nThe above annotation will pause autoscaling. To enable autoscaling again, simply remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.14/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.14/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\nTo deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.14.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.14.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.14.1-core.yaml\n```\n\n> 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details.\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.14.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.14.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.14.1/keda-2.14.1-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.14.1.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.14.1-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.14.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.14/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.14/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.14/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.14/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. Replaced by `keda_scaler_metrics_latency_seconds`.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler. Replaced by `keda_scaler_detail_errors_total`.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers. Replaced by `keda_scaler_detail_errors_total`.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. Replaced by `keda_scaled_object_errors_total`.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). Replaced by `keda_resource_registered_total`.\n- `keda_trigger_totals` - Total number of triggers per trigger type. Replaced by `keda_trigger_registered_total`.\n- `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. Replaced by `keda_internal_scale_loop_latency_seconds`.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.14/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.14/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.14/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n"
  },
  {
    "path": "content/docs/2.14/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                    | Scenario Description                                                                                                        | \n|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| \n| `keda.scaledobject.ready.v1`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails                                                                            |      \n"
  },
  {
    "path": "content/docs/2.14/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.14/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | \n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    | \n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails |                                                                           |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails            |                                                                     |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch |                                                                    |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch |                                                                       |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob |                                                           |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob |                                                         |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source|                                                                       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...}|                                         |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0 |                                        |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1|                                                              |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0|                                                              |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob |                                                                                       |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added|                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted|                                                                                       |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added|                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted|                                                                                |\n\n\n## CloudEvent Support (Experimental)\n\n### Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n### Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n#### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n#### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n##### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n##### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n### Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n### Supported Event List\n| Event Type                                | Scenario Description                                                                                                                 | \n| ------------------------------------- |  --------------------------------------------------------------------------------------------------------------------------- | \n| `keda.scaledobject.ready.v1`                   | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1`             | If the check validation for a ScaledObject fails |      "
  },
  {
    "path": "content/docs/2.14/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (just an external metric):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.14/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, you need to ensure that the certs are in `/custom/ca` folder and KEDA will try to register as trusted CAs all certificates inside this folder. This can be done with kustomize or helm (using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`).\n"
  },
  {
    "path": "content/docs/2.14/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)"
  },
  {
    "path": "content/docs/2.14/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | \n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    | \n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |                                                                           |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |                                                                     |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |                                                                    |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |                                                                       |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |                                                           |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |                                                         |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |                                                                       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |                                         |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |                                        |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |                                                              |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |                                                              |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |                                                                                       |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |                                                                                       |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |                                                                                |\n"
  },
  {
    "path": "content/docs/2.14/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_14\" >}}\n"
  },
  {
    "path": "content/docs/2.14/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## GRPC\n\nGo Remote Procedure Call. An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.14/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA \n\nto scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.14/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n### scalingModifiers\n\nThe `scalingModifiers` is optional and **experimental**. If defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md#scaling-modifiers-experimental).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.14/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.14/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.14/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` and `aws-kiam` authentications)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated only applies for `aws-eks` and `aws-kiam` authentications, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](./../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.14/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n## Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n## Cases of unexpected metrics value in DataDog API response\n\n### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.14/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```"
  },
  {
    "path": "content/docs/2.14/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    activationValue: \"10.5\" # Optional - Default is 0\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    format: \"json\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n**TLS Authentication**\n\n- `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### Example without any TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with no TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n\n#### Example with TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-stan-secrets\n  namespace: default\ndata:\n  tls: enable\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-stan-secrets\n      key: tls\n    - parameter: ca\n      name: keda-stan-secrets\n      key: ca\n    - parameter: cert\n      name: keda-stan-secrets\n      key: cert\n    - parameter: key\n      name: keda-stan-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"true\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.14/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.14/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of customHeaders and will be removed in version 2.12. Use custom headers instead to set X-Scope-OrgID header for Cortex. (see below)\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - DEPRECATED: This parameter is deprecated as of KEDA v2.10 in favor of `customHeaders` and will be removed in version 2.12. Use `customHeaders: X-Scope-OrgID=##` instead to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload # use \"azure\" for pod identity and \"azure-workload\" for workload identity\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.14/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    unsafeSsl: true\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.14/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n      platformName: 'Linux' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.14/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.14/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.14/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.15/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. \n\nUse the navigation bar on the left to learn more about KEDA's architecture  and how to deploy and use KEDA.\n\n## Where to go\n\nWhat is your involvement with KEDA?\n\n| Role                      | Documentation                                                                                                                                                |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| User                      | This documentation is for users who want to deploy KEDA to scale Kubernetes.                                                                                 |\n| Core Contributor          | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda).                                                         |\n| Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). |\n| Other Contributor         | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers.            |\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nAttach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional.\n    serviceAccount: {path-to-service-account-file}            # Optional.\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.15/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.15/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.15/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.15/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure-workload | aws | aws-eks | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                              # Required.\n      path: {hashicorp-vault-secret-path}                                 # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure-workload                                            # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure-workload | aws | aws-eks | gcp               # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```"
  },
  {
    "path": "content/docs/2.15/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec).\n> Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.15/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\nThis page describes the deployment scaling behavior of KEDA. \n\n# Specification\n\nSee the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below.\n\n# Scaling objects\n\n## Scaling Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## Scaling Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n# Features\n\n## Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval.\n\nEnabling this feature can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n## Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledObject` definition:\n\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`.\n\n\n## Scaling Modifiers\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n\n## Activating and Scaling thresholds\n\nKEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transferring ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disabling validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n### Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n#### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n#### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](./scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.15/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\nThis page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below.\n\n\n# Overview\n\nAs an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n\n# Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nTo reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: false\n```\n\n\n## Example\n\nAn example configuration for autoscaling jobs using a RabbitMQ scaler is given below. \n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.15/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.15/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- Helm charts\n- Operator Hub\n- YAML declarations\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nTo deploy KEDA with Helm:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\nTo deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.15.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.15.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.15.1-core.yaml\n```\n\n> 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details.\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.15.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.15.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.15.1/keda-2.15.1-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.15.1.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.15.1-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.15.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s add-ons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, disable the add-on as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.15/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.15/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.15/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.15/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n> Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed.\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. Replaced by `keda_scaler_metrics_latency_seconds`.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler. Replaced by `keda_scaler_detail_errors_total`.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers. Replaced by `keda_scaler_detail_errors_total`.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. Replaced by `keda_scaled_object_errors_total`.\n- `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob. Replace by `keda_scaled_job_errors_total`.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). Replaced by `keda_resource_registered_total`.\n- `keda_trigger_totals` - Total number of triggers per trigger type. Replaced by `keda_trigger_registered_total`.\n- `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. Replaced by `keda_internal_scale_loop_latency_seconds`.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.15/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.15/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance and requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance and requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](../reference/events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.15/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n\n## Custom Validations using Kubernetes ValidatingAdmissionPolicy\n\n> ⚠️ FEATURE STATE: Kubernetes v1.30 [stable]\n\nKubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).\n\nHere is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10):\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-keda-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"keda.sh\"]\n      apiVersions: [\"v1alpha1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"scaledobjects\"]\n  validations:\n    - expression: \"object.spec.maxReplicaCount <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-keda-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-keda-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```\n\nSince KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas:\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-apps-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"apps\"]\n      apiVersions: [\"v1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"deployments\", \"replicasets\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-hpa-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"autoscaling\"]\n      apiVersions: [\"v2\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"horizontalpodautoscalers\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-apps-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-apps-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-hpa-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-hpa-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```"
  },
  {
    "path": "content/docs/2.15/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n### Scopes: Namespace vs. Cluster\n\nEach `CloudEventSource` is defined in one namespace and will only subscribe to events inside that namespace. If you want to subscribe to events in all namespaces, you can instead create a `ClusterCloudEventSource` resource.\n\nDefining a `ClusterCloudEventSource` works almost identically to a `CloudEventSource`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterCloudEventSource\nmetadata:\n  name: {cluster-cloudeventsource-name}\nspec:\n  # As before ..\n```\n  \n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                    | Scenario Description                                                                                                        | \n|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| \n| `keda.scaledobject.ready.v1`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails                                                                            |  \n| `keda.scaledobject.removed.v1`| When a ScaledObject is deleted |       \n"
  },
  {
    "path": "content/docs/2.15/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.15 | v1.28 - v1.30 |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.15/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (external metrics only):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.15/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory.  Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`.\n"
  },
  {
    "path": "content/docs/2.15/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Kubernetes Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)\n"
  },
  {
    "path": "content/docs/2.15/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | \n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    | \n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |                                                                           |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |                                                                     |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |                                                                    |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |                                                                       |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |                                                           |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |                                                         |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |                                                                       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |                                         |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |                                        |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |                                                              |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |                                                              |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |                                                                                       |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |                                                                                       |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |                                                                                |\n"
  },
  {
    "path": "content/docs/2.15/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_15\" >}}\n"
  },
  {
    "path": "content/docs/2.15/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## gRPC Remote Procedure Calls (gRPC)\n\ngRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.15/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale `Job` resources. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n**eager**\nWhen adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.\n\nFor example, let's assume we configure a ScaledJob in a cluster as below:\n```yaml\n  ###\n  # A job that runs for a minimum of 3 hours.\n  ###\n  pollingInterval: 10 # Optional. Default: 30 seconds\n  maxReplicaCount: 10 # Optional. Default: 100\n  triggers:\n    - type: rabbitmq\n      metadata:\n        queueName: woker_queue\n        hostFromEnv: RABBITMQ_URL\n        mode: QueueLength\n        value: \"1\"\n```\nWe send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.\n\nWith the `default` scaling strategy, we are supposed to see the metrics changes in the following table:\n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 3          |\n\n\nIf we switch to `eager`, the result becomes: \n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 6          |\n\nWe can identify the difference in their final states.\n\n\nYou may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.15/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n### scalingModifiers\n\nIf defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.15/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.15/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Datastore\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.15/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n\n> When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n### Links\n\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not use demands in your agent scaler then it scales based on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    queueLengthStrategy: all|visibleonly\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      # Optional\n      queueLengthStrategy: \"all\" # or visibleonly. Default: all\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n- `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional).\n- `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional)\n- `key` - Key path for client authentication. Mandatory if tls enabled. (Optional)\n\n### Example with no TLS auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n\n### Example with TLS auth\n\nSince we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. \n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/cassandra\n            name: temp-cassandra-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-cassandra-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/cassandra\n  name: temp-cassandra-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-cassandra-vol\n  emptyDir:\n    medium: Memory\n```\n\nOnce we have the writable mount path set up for the certificates and keys.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n  tls: enable\n  cert: <cert content | base64encoded>\n  key: <key content | base64encoded>\n  ## Optional parameter ca ##\n  ca: <ca cert content | base64encoded>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n  - parameter: tls\n    name: cassandra-secrets\n    key: tls\n  - parameter: cert\n    name: cassandra-secrets\n    key: cert\n  - parameter: key\n    name: cassandra-secrets\n    key: key\n  ## Optional parameter ca ##\n  - parameter: ca\n    name: cassandra-secrets\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.15/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\nThere are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately.\n\n## Using the Datadog Cluster Agent (Experimental)\n\nWith this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches.\n\n### Deploy the Datadog Cluster Agent with enabled external metrics\n\nFirst, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA).\n\nIf you are using Helm to deploy the Cluster Agent, set:\n\n* `clusterAgent.metricsProvider.enabled` to `true`\n* `clusterAgent.metricsProvider.registerAPIService` to `false`\n* `clusterAgent.metricsProvider.useDatadogMetrics` to `true`\n* `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]`\n\nIf you are using the Datadog Operator, add the following options to your `DatadogAgent` object:\n\n```\napiVersion: datadoghq.com/v2alpha1\nkind: DatadogAgent\nmetadata:\n  name: datadog\nspec:\n  features:\n    externalMetricsServer:\n      enabled: true\n      useDatadogMetrics: true\n      registerAPIService: false\n  override:\n    clusterAgent:\n      env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]\n[...]\n```\n\nNOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later.\n\n### Create a DatadogMetric object for each scaling query\n\nTo use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: \"true\"` annotation, to ensure the Cluster Agent retrieves the query value. Example:\n\n```yaml\napiVersion: datadoghq.com/v1alpha1\nkind: DatadogMetric\nmetadata:\n  annotations:\n    external-metrics.datadoghq.com/always-active: \"true\"\n  name: nginx-hits\nspec:\n  query: sum:nginx.net.request_per_s{kube_deployment:nginx}\n```\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"true\"\n    datadogMetricName: \"nginx-hits\"\n    datadogMetricNamespace: \"default\"\n    targetValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional)\n- `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events.\n- `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events.\n- `targetValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nThe Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Common to all authentication types**\n- `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional)\n- `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed.\n- `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern.\n- `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional)\n\n**Bearer authentication:**\n- `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-config\n  namespace: my-project\ntype: Opaque\ndata:\n  datadogNamespace: # Required: base64 encoded value of the namespace where the Datadog Cluster Agent is deployed\n  datadogMetricsService: # Required: base64 encoded value of the Cluster Agent metrics server service\n  unsafeSsl: # Optional: base64 encoded value of `true` or `false`\n  authMode: # Required: base64 encoded value of the authentication mode (in this case, bearer)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: datadog-cluster-agent-creds\n  namespace: my-project\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: dd-cluster-agent-token\n      key: token\n    - parameter: datadogNamespace\n      name: datadog-config\n      key: datadogNamespace\n    - parameter: unsafeSsl\n      name: datadog-config\n      key: unsafeSsl\n    - parameter: authMode\n      name: datadog-config\n      key: authMode\n    - parameter: datadogMetricsService\n      name: datadog-config\n      key: datadogMetricsService\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx\n  maxReplicaCount: 3\n  minReplicaCount: 1\n  pollingInterval: 60\n  triggers:\n  - type: datadog\n    metadata:\n      useClusterAgentProxy: \"true\"\n      datadogMetricName: \"nginx-hits\"\n      datadogMetricNamespace: \"default\"\n      targetValue: \"2\"\n      type: \"global\"\n    authenticationRef:\n      name: datadog-cluster-agent-creds\n```\n\n## Using the Datadog REST API\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"false\"\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false)\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n### Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../reference/scaledobject-spec/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n### Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n#### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n#### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n### Cases of unexpected metrics value in DataDog API response\n\n#### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n#### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.15/scalers/dynatrace.md",
    "content": "+++\ntitle = \"Dynatrace\"\navailability = \"2.15+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Dynatrace metric data points\"\ngo_file = \"dynatrace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points.\n\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      host: https://dummy-instance.live.dynatrace.com/\n      metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n      # Optional\n      from: now-2d\n      threshold: \"10\"\n      # Optional\n      activationThreshold: \"5\"\n```\n\n**Parameter list:**\n\n- `host` - The Dynatrace instance to query against\n- `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)).\n\n  Some relevant aspects:\n    - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered\n    - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered\n    - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector\n- `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters.\n\n**Authentication:**\n\n- `host` - The Dynatrace instance to query against\n- `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/\n  token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n        from: 'now-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```"
  },
  {
    "path": "content/docs/2.15/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    filterDuration: '1' # Optional - Default is 2\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    valueIfNull: '0.0' # Optional - Default is \"\"\n    activationValue: \"10.5\" # Optional - Default is 0\n    timeHorizon: \"1m\" # Optional - Default is 2m and with aggregation 5m\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`)\n\n- `valueIfNull` - Value returned if request returns no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    filterDuration: '1' # Optional - Default is 2\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n    unsafeSsl: <SSL enabled/disabled> # OPTIONAL - Set 'true' for unsafe SSL. Default: false\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\nExample with Basic Auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n\n### Example\n\nExample with Basic Auth and TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n  cert: <your tls.crt>\n  key: <your tls.key>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n    - parameter: cert\n      name: keda-ibmmq-secret\n      key: cert\n    - parameter: key\n      name: keda-ibmmq-secret\n      key: key\n```\n\n"
  },
  {
    "path": "content/docs/2.15/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    format: \"json\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n**TLS Authentication**\n\n- `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### Example without any TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with no TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n\n#### Example with TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-stan-secrets\n  namespace: default\ndata:\n  tls: enable\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-stan-secrets\n      key: tls\n    - parameter: ca\n      name: keda-stan-secrets\n      key: ca\n    - parameter: cert\n      name: keda-stan-secrets\n      key: cert\n    - parameter: key\n      name: keda-stan-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"true\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.15/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.15/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for three connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret).\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nIt is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity.  \nMore details and an example are provided down below.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n\n**Azure Access Token authentication:**\n\n#### Prerequisites:\n- The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity).\n- The UAMI should be granted access to the table mentioned in the query performed by KEDA.  \nThis can be achieved by:\n  - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role.\n  - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like  \n  `GRANT ALL ON <TABLE_REF> TO \"<AZURE_UAMI_NAME>\";`.\n\nNext, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process.\n  - `host` - FQDN of the Azure Postgres Flexible Server.\n  - `userName` - Name of the UAMI Azure identity (`<AZURE_UAMI_NAME>`).\n  - `port` - Postgresql port (the default value is `\"5432\"`, please have a look at the `Remarks` down below).\n  - `dbName` - Postgresql Database name.\n  - `sslmode` - SSL policy for communicating with database (the value should be `require`).\n\n\n#### Remarks\n\n- While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port.\n\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-pg-flex-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      authenticationRef:\n        name: azure-pg-flex-auth\n      metadata:\n        host: <AZURE_POSTGRES_FLEX_SERVER_FQDN>\n        port: \"5432\"\n        userName: <UAMI_NAME>\n        dbName: <DB_NAME>\n        sslmode: require\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```"
  },
  {
    "path": "content/docs/2.15/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.15/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    unsafeSsl: true\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"myprimary\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.15/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n      platformName: 'Linux' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Default: `Linux`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.15/scalers/splunk.md",
    "content": "+++\ntitle = \"Splunk\"\navailability = \"v2.15+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk saved search results.\"\ngo_file = \"splunk_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches).\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: splunk\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"1\"\n      activationValue: \"10\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n**Parameter list:**\n\n- `host` - Search API host and port. Example: `https://localhost:8089`.\n- `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `\"true\"`, `\"false\"`, Default: `\"false\"`, Optional)\n- `targetValue` - Value to reach to start scaling (This value can be a integer or float).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `savedSearchName` - Name of saved search that returns metric data for scaling.\n- `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`.\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication.\n\n> **Note:**\n>\n> `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API.\n\n**Parameter list:**\n\n- `username` - Splunk username authorized to access the search API.\n- `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`.\n- `password` - Password for supplied `username`. Conflicts with `apiToken`.\n\nThe user will need access to the saved search.\n\n### Examples\n\n### Username/password\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### API Token\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # admin\n  apiToken: <base64 encoded api token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: apiToken\n      name: splunk-creds\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### Full example using Splunk deployment\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: splunkconf\ndata:\n  default.yml: |\n    splunk:\n      conf:\n        - key: savedsearches\n          value:\n            directory: /opt/splunk/etc/users/admin/search/local\n            content:\n              my-saved-search-name:\n                action.email.useNSSubject: 1\n                action.webhook.enable_allowlist: 0\n                alert.track: 0\n                cron_schedule: '*/1 * * * *'\n                dispatch.earliest_time: -15m\n                dispatch.latest_time: now\n                display.general.type: statistics\n                display.page.search.tab: statistics\n                display.visualizations.show: 0\n                enableSched: 1\n                request.ui_dispatch_app: search\n                request.ui_dispatch_view: search\n                search: index=_internal | tail | stats count\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: splunk\nspec:\n  ports:\n    - port: 8000\n      targetPort: web\n      name: web-svc\n    - port: 8089\n      targetPort: 8089\n      name: api-svc\n  selector:\n    app: splunk\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: splunk\n  namespace: default\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: splunk\n  template:\n    metadata:\n      labels:\n        app: splunk\n    spec:\n      containers:\n      - name: splunk\n        image: splunk/splunk:9.2\n        ports:\n          - containerPort: 8000\n            name: web\n          - containerPort: 8089\n            name: api\n        env:\n          - name: SPLUNK_START_ARGS\n            value: --accept-license\n          - name: SPLUNK_PASSWORD\n            value: password\n        volumeMounts:\n          - name: splunkconf-volume\n            mountPath: /tmp/defaults\n      volumes:\n        - name: splunkconf-volume\n          configMap:\n            name: splunkconf\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx\n        ports:\n        - containerPort: 8080\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      unsafeSsl: \"true\"\n      targetValue: \"5\"\n      activationValue: \"5\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n"
  },
  {
    "path": "content/docs/2.15/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.15/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.16/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. \n\nUse the navigation bar on the left to learn more about KEDA's architecture  and how to deploy and use KEDA.\n\n## Where to go\n\nWhat is your involvement with KEDA?\n\n| Role                      | Documentation                                                                                                                                                |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| User                      | This documentation is for users who want to deploy KEDA to scale Kubernetes.                                                                                 |\n| Core Contributor          | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda).                                                         |\n| Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). |\n| Other Contributor         | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers.            |\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nAttach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional.\n    serviceAccount: {path-to-service-account-file}            # Optional.\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.16/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.16/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs three key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n2. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n3. **Admission Webhooks** - Automatically validate resource changes to prevent misconfiguration and enforce best practices by using an [admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/). As an example, it will prevent multiple ScaledObjects to target the same scale target.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.16/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.16/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure-workload | aws | aws-eks | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                              # Required.\n      path: {hashicorp-vault-secret-path}                                 # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure-workload                                            # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure-workload | aws | aws-eks | gcp               # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```"
  },
  {
    "path": "content/docs/2.16/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec).\n> Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.16/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\nThis page describes the deployment scaling behavior of KEDA. \n\n# Specification\n\nSee the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below.\n\n# Scaling objects\n\n## Scaling Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## Scaling Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n# Features\n\n## Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval.\n\nEnabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n## Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledObject` definition:\n\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`.\n\n\n## Scaling Modifiers\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n\n## Activating and Scaling thresholds\n\nKEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transferring ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disabling validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n### Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n#### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n#### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](./scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.16/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\nThis page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below.\n\n\n# Overview\n\nAs an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n\n# Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nTo reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: false\n```\n\n\n## Example\n\nAn example configuration for autoscaling jobs using a RabbitMQ scaler is given below. \n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.16/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.16/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- Helm charts\n- Operator Hub\n- YAML declarations\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.27 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nTo deploy KEDA with Helm:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\nTo deploy the CRDs separately from the Helm chart, use the `keda-2.xx.x-crds.yaml` file provided on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page. \n  - We offer two options to deploy KEDA:\n    - Use `keda-2.xx.x.yaml` that includes all features, including [admission webhooks](./concepts/admission-webhooks.md) (recommended)\n    - Use `keda-2.xx.x-core.yaml` that installs the minimal required KEDA components, without admission webhooks\n\nRun the following command (if needed, replace the version, in this case `2.16.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1-core.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.16.1.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.16.1-core.yaml\n```\n\n> 💡 **NOTE:** `--server-side` option is needed because the ScaledJob CRD is too long to process, see [this issue](https://github.com/kedacore/keda/issues/4740) for details.\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.16.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.16.1`, with the one you are using):\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.16.1/keda-2.16.1-core.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.16.1.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.16.1-core.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.16.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s add-ons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, disable the add-on as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.16/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.16/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.16/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.16/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n> Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed.\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n- `keda_scaler_metrics_latency` - The latency of retrieving current metric from each scaler. Replaced by `keda_scaler_metrics_latency_seconds`.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler. Replaced by `keda_scaler_detail_errors_total`.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers. Replaced by `keda_scaler_detail_errors_total`.\n- `keda_scaled_object_errors` - The number of errors that have occurred for each ScaledObject. Replaced by `keda_scaled_object_errors_total`.\n- `keda_scaled_job_errors` - The number of errors that have occurred for each ScaledJob. Replace by `keda_scaled_job_errors_total`.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD). Replaced by `keda_resource_registered_total`.\n- `keda_trigger_totals` - Total number of triggers per trigger type. Replaced by `keda_trigger_registered_total`.\n- `keda_internal_scale_loop_latency` - Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. Replaced by `keda_internal_scale_loop_latency_seconds`.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.16/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.16/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance and requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance and requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](../reference/events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.16/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n\n### Cache Miss with Fallback to Direct Client for ScaledObject\n\nWhen validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`:\n```\n--cache-miss-to-direct-client=true\n```\nThis will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API.\n\n\n## Custom Validations using Kubernetes ValidatingAdmissionPolicy\n\n> ⚠️ FEATURE STATE: Kubernetes v1.30 [stable]\n\nKubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).\n\nHere is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10):\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-keda-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"keda.sh\"]\n      apiVersions: [\"v1alpha1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"scaledobjects\"]\n  validations:\n    - expression: \"object.spec.maxReplicaCount <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-keda-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-keda-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```\n\nSince KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas:\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-apps-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"apps\"]\n      apiVersions: [\"v1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"deployments\", \"replicasets\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-hpa-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"autoscaling\"]\n      apiVersions: [\"v2\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"horizontalpodautoscalers\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-apps-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-apps-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-hpa-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-hpa-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```"
  },
  {
    "path": "content/docs/2.16/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                    | Scenario Description                                                                                                        | \n|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| \n| `keda.scaledobject.ready.v1`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails                                                                            |  \n| `keda.scaledobject.removed.v1`| When a ScaledObject is deleted |       \n| `keda.scaledjob.ready.v1`| On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledjob.failed.v1`| If the check validation for a ScaledJob fails                                    \n| `keda.scaledjob.removed.v1`| When a ScaledJob is deleted |  \n| `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created |\n| `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | \n| `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted |  \n| `keda.authentication.clustertriggerauthentication.created.v1`|  On the first time a ClusterTriggerAuthentication is created |\n| `keda.authentication.clustertriggerauthentication.updated.v1`| When a ClusterTriggerAuthentication is updated | \n| `keda.authentication.clustertriggerauthentication.removed.v1`| When a ClusterTriggerAuthentication is deleted |  "
  },
  {
    "path": "content/docs/2.16/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.16 | v1.29 - v1.31 |\n| v2.15 | v1.28 - v1.30 |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment | Default Value | Manager Property |\n| -------------------------------------------- | ---------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator   | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator   | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator   | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.16/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (external metrics only):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.16/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory.  Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`.\n"
  },
  {
    "path": "content/docs/2.16/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Kubernetes Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)\n"
  },
  {
    "path": "content/docs/2.16/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | \n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    | \n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |                                                                           |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |                                                                     |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |                                                                    |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |                                                                       |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |                                                           |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |                                                         |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |                                                                       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |                                         |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |                                        |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |                                                              |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |                                                              |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |                                                                                       |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |                                                                                       |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |                                                                                |\n"
  },
  {
    "path": "content/docs/2.16/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_15\" >}}\n"
  },
  {
    "path": "content/docs/2.16/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## gRPC Remote Procedure Calls (gRPC)\n\ngRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.16/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n**eager**\nWhen adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.\n\nFor example, let's assume we configure a ScaledJob in a cluster as below:\n```yaml\n  ###\n  # A job that runs for a minimum of 3 hours.\n  ###\n  pollingInterval: 10 # Optional. Default: 30 seconds\n  maxReplicaCount: 10 # Optional. Default: 100\n  triggers:\n    - type: rabbitmq\n      metadata:\n        queueName: woker_queue\n        hostFromEnv: RABBITMQ_URL\n        mode: QueueLength\n        value: \"1\"\n```\nWe send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.\n\nWith the `default` scaling strategy, we are supposed to see the metrics changes in the following table:\n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 3          |\n\n\nIf we switch to `eager`, the result becomes: \n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 6          |\n\nWe can identify the difference in their final states.\n\n\nYou may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.16/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N.\n\nIf you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly.\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n### scalingModifiers\n\nIf defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.16/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.16/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Datastore\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.16/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Optional: ignoreNullValues\n    ignoreNullValues: \"false\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response.  If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional)\n\n> Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload.\n\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n\n> When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n### Links\n\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not use demands in your agent scaler then it scales based on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored). If `requireAllDemands` is set to `true` it is checked if a jobs demands are fulfilled exactly by a trigger and only scales if this is true. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    queueLengthStrategy: all|visibleonly\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      # Optional\n      queueLengthStrategy: \"all\" # or visibleonly. Default: all\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/beanstalkd.md",
    "content": "+++\ntitle = \"Beanstalkd\"\navailability = \"v2.16+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on beanstalkd queues\"\ngo_file = \"beanstalkd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue.\n\n```yaml\ntriggers:\n  - type: beanstalkd\n    metadata:\n      server: beanstalkd.internal-namespace:11300\n      includeDelayed: \"false\"\n      tube: \"default\"\n      activationValue: \"10\"\n      value: \"15\"\n      timeout: \"30\"\n```\n\n**Parameter list:**\n\n- `server` - Address of beanstalkd server `<host>:<port>`. If no port is specified then the scaler will default to `11300`.\n- `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted.\n- `tube` - Name of the tube to scale on.\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set.\n- `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional)\n\n### Authentication Parameters\n\nNo authentication should be needed to connect to the beanstalkd server.\n\n### Example\n\n#### Default tube with activation value\n\nHere the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'default'\n        activationValue: \"10\"\n        value: \"20\"\n```\n\n#### User-created tube with minimum replicas\n\nA minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'scaling-tube'\n        value: \"5\"\n        includeDelayed: \"true\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n- `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional).\n- `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional)\n- `key` - Key path for client authentication. Mandatory if tls enabled. (Optional)\n\n### Example with no TLS auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n\n### Example with TLS auth\n\nSince we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. \n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/cassandra\n            name: temp-cassandra-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-cassandra-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/cassandra\n  name: temp-cassandra-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-cassandra-vol\n  emptyDir:\n    medium: Memory\n```\n\nOnce we have the writable mount path set up for the certificates and keys.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n  tls: enable\n  cert: <cert content | base64encoded>\n  key: <key content | base64encoded>\n  ## Optional parameter ca ##\n  ca: <ca cert content | base64encoded>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n  - parameter: tls\n    name: cassandra-secrets\n    key: tls\n  - parameter: cert\n    name: cassandra-secrets\n    key: cert\n  - parameter: key\n    name: cassandra-secrets\n    key: key\n  ## Optional parameter ca ##\n  - parameter: ca\n    name: cassandra-secrets\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.16/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\nThere are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately.\n\n## Using the Datadog Cluster Agent (Experimental)\n\nWith this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches.\n\n### Deploy the Datadog Cluster Agent with enabled external metrics\n\nFirst, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA).\n\nIf you are using Helm to deploy the Cluster Agent, set:\n\n* `clusterAgent.metricsProvider.enabled` to `true`\n* `clusterAgent.metricsProvider.registerAPIService` to `false`\n* `clusterAgent.metricsProvider.useDatadogMetrics` to `true`\n* `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]`\n\nIf you are using the Datadog Operator, add the following options to your `DatadogAgent` object:\n\n```\napiVersion: datadoghq.com/v2alpha1\nkind: DatadogAgent\nmetadata:\n  name: datadog\nspec:\n  features:\n    externalMetricsServer:\n      enabled: true\n      useDatadogMetrics: true\n      registerAPIService: false\n  override:\n    clusterAgent:\n      env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]\n[...]\n```\n\nNOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later.\n\n### Create a DatadogMetric object for each scaling query\n\nTo use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: \"true\"` annotation, to ensure the Cluster Agent retrieves the query value. Example:\n\n```yaml\napiVersion: datadoghq.com/v1alpha1\nkind: DatadogMetric\nmetadata:\n  annotations:\n    external-metrics.datadoghq.com/always-active: \"true\"\n  name: nginx-hits\nspec:\n  query: sum:nginx.net.request_per_s{kube_deployment:nginx}\n```\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"true\"\n    datadogMetricName: \"nginx-hits\"\n    datadogMetricNamespace: \"default\"\n    targetValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional)\n- `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events.\n- `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events.\n- `targetValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nThe Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Common to all authentication types**\n- `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional)\n- `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed.\n- `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern.\n- `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional)\n\n**Bearer authentication:**\n- `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-config\n  namespace: my-project\ntype: Opaque\ndata:\n  datadogNamespace: # Required: base64 encoded value of the namespace where the Datadog Cluster Agent is deployed\n  datadogMetricsService: # Required: base64 encoded value of the Cluster Agent metrics server service\n  unsafeSsl: # Optional: base64 encoded value of `true` or `false`\n  authMode: # Required: base64 encoded value of the authentication mode (in this case, bearer)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: datadog-cluster-agent-creds\n  namespace: my-project\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: dd-cluster-agent-token\n      key: token\n    - parameter: datadogNamespace\n      name: datadog-config\n      key: datadogNamespace\n    - parameter: unsafeSsl\n      name: datadog-config\n      key: unsafeSsl\n    - parameter: authMode\n      name: datadog-config\n      key: authMode\n    - parameter: datadogMetricsService\n      name: datadog-config\n      key: datadogMetricsService\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx\n  maxReplicaCount: 3\n  minReplicaCount: 1\n  pollingInterval: 60\n  triggers:\n  - type: datadog\n    metadata:\n      useClusterAgentProxy: \"true\"\n      datadogMetricName: \"nginx-hits\"\n      datadogMetricNamespace: \"default\"\n      targetValue: \"2\"\n      type: \"global\"\n    authenticationRef:\n      name: datadog-cluster-agent-creds\n```\n\n## Using the Datadog REST API\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"false\"\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false)\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n### Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../reference/scaledobject-spec/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n### Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n#### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n#### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n### Cases of unexpected metrics value in DataDog API response\n\n#### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n#### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.16/scalers/dynatrace.md",
    "content": "+++\ntitle = \"Dynatrace\"\navailability = \"2.15+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Dynatrace metric data points\"\ngo_file = \"dynatrace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points.\n\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      host: https://dummy-instance.live.dynatrace.com/\n      metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n      # Optional\n      from: now-2d\n      threshold: \"10\"\n      # Optional\n      activationThreshold: \"5\"\n```\n\n**Parameter list:**\n\n- `host` - The Dynatrace instance to query against\n- `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)).\n\n  Some relevant aspects:\n    - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered\n    - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered\n    - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector\n- `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters.\n\n**Authentication:**\n\n- `host` - The Dynatrace instance to query against\n- `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/\n  token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n        from: 'now-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html).\n\nThe trigger always requires the following information, but requires either only searchTemplateName **or** only query:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      query: \"my-query\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `query` - The query to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Examples\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        query: |\n          {\n            \"size\": 0,\n            \"query\": {\n              \"bool\": {\n                \"must\": [\n                  {\n                    \"term\": {\n                      \"service.name\": \"my-application\" }\n                  },\n                  {\n                    \"term\": {\n                      \"service.environment\": \"production\" }\n                  },\n                  {\n                    \"range\": {\n                      \"@timestamp\": {\n                        \"gte\": \"now-2m\",\n                        \"lte\": \"now-1m\"\n                      }\n                    }\n                  }\n                ]\n              }\n            },\n            \"aggs\": {\n              \"transaction_count\": {\n                \"cardinality\": {\n                  \"field\": \"transaction.id\" }\n              }\n            }\n          }\n        valueLocation: \"aggregations.transaction_count.value\"\n        targetValue: \"1000\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n        usernameFromEnv: <admin-user>  # Optional\n        passwordFromEnv: <admin-password> # Optional\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Password based authentication:**\n\n- `username` - Username for authentication. (Optional)\n- `password` - Password for authentication. (Optional)\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on Password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  etcd-username: <your username>\n  etcd-password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-etcd-secrets\n      key: etcd-username\n    - parameter: password\n      name: keda-etcd-secrets\n      key: etcd-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```"
  },
  {
    "path": "content/docs/2.16/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    filterDuration: '1' # Optional - Default is 2\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    valueIfNull: '0.0' # Optional - Default is \"\"\n    activationValue: \"10.5\" # Optional - Default is 0\n    timeHorizon: \"1m\" # Optional - Default is 2m and with aggregation 5m\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`)\n\n- `valueIfNull` - Value returned if request returns no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    filterDuration: '1' # Optional - Default is 2\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\", defaults to \"false\" (scale on default runner labels)\n      noDefaultLabels: \"{noDefaultLabels}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabels` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"). (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabelsFromEnv` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\". (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls and affect the Rate Limit.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. The scaler will make 1 request per repository to get the list of workflows, \nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout can help reduce the number of API calls. Usage of the `repos` parameter is recommended to reduce the number of API calls to the GitHub API.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n    unsafeSsl: \"false\" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ).\n- `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional)\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18, Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\nExample with Basic Auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n        usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n\nExample with Basic Auth and TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n  cert: <your tls.crt>\n  key: <your tls.key>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n    - parameter: cert\n      name: keda-ibmmq-secret\n      key: cert\n    - parameter: key\n      name: keda-ibmmq-secret\n      key: key\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    format: \"json\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n**TLS Authentication**\n\n- `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### Example without any TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with no TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n\n#### Example with TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-stan-secrets\n  namespace: default\ndata:\n  tls: enable\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-stan-secrets\n      key: tls\n    - parameter: ca\n      name: keda-stan-secrets\n      key: ca\n    - parameter: cert\n      name: keda-stan-secrets\n      key: cert\n    - parameter: key\n      name: keda-stan-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"true\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.16/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.16/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for three connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret).\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nIt is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity.  \nMore details and an example are provided down below.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n\n**Azure Access Token authentication:**\n\n#### Prerequisites:\n- The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity).\n- The UAMI should be granted access to the table mentioned in the query performed by KEDA.  \nThis can be achieved by:\n  - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role.\n  - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like  \n  `GRANT ALL ON <TABLE_REF> TO \"<AZURE_UAMI_NAME>\";`.\n\nNext, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process.\n  - `host` - FQDN of the Azure Postgres Flexible Server.\n  - `userName` - Name of the UAMI Azure identity (`<AZURE_UAMI_NAME>`).\n  - `port` - Postgresql port (the default value is `\"5432\"`, please have a look at the `Remarks` down below).\n  - `dbName` - Postgresql Database name.\n  - `sslmode` - SSL policy for communicating with database (the value should be `require`).\n\n\n#### Remarks\n\n- While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port.\n\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-pg-flex-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      authenticationRef:\n        name: azure-pg-flex-auth\n      metadata:\n        host: <AZURE_POSTGRES_FLEX_SERVER_FQDN>\n        port: \"5432\"\n        userName: <UAMI_NAME>\n        dbName: <DB_NAME>\n        sslmode: require\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```"
  },
  {
    "path": "content/docs/2.16/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.16/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of TriggerAuthentication\n    passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of TriggerAuthentication\n    unsafeSsl: true\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username to use to connect to the broker's management endpoint.\n- `passwordFromEnv` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n**Username and Password based authentication:**\n\nThis allows sensitive credentials to be stored and managed separately from the connection string.\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** If username or password are set in TriggerAuthentication or environment variables, they will override any credentials provided in the host.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQP protocol with user/password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://localhost:5672/vhost (no username/password)\n  username: <username> # base64 encoded value of username\n  password: <password> # base64 encoded value of password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: username\n      name: keda-rabbitmq-secret\n      key: username\n    - parameter: password\n      name: keda-rabbitmq-secret\n      key: password \n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"myprimary\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.16/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars, SeleniumHQ\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration with default values represent.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: ''  # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`).\n      browserVersion: '' # Optional.\n      platformName: '' # Optional.\n      unsafeSsl : 'false' # Optional.\n      activationThreshold: 0 # Optional.\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional).\n\n**Trigger Authentication**\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional)\n- `accessToken` - Access token. This is required when `authType` is set a value. (Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl : 'true'\n```\n\nNoted:\n- From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details.\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nWith above script, the request is sent to Grid. Via GraphQL response, it looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 0,\n      \"totalSlots\": 0\n    },\n    \"nodesInfo\": {\n      \"nodes\": []\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nIn Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which is set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata.\n\nWhen the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 1,\n      \"totalSlots\": 1\n    },\n    \"nodesInfo\": {\n      \"nodes\": [\n        {\n          \"id\": \"UUID-of-Node\",\n          \"status\": \"UP\",\n          \"sessionCount\": 0,\n          \"maxSession\": 1,\n          \"slotCount\": 1,\n          \"stereotypes\": \"[{\\\"slots\\\": 1, \\\"stereotype\\\": {\\\"browserName\\\": \\\"chrome\\\", \\\"browserVersion\\\": \\\"\\\", \\\"platformName\\\": \\\"Linux\\\"}}]\",\n          \"sessions\": []\n        }\n      ]\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nNow, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in.\n\nMoreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome-131\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:131.0\n        ports:\n        - containerPort: 5555\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-131\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-131\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '131.0'\n        unsafeSsl : 'true'\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '131.0')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nSimilarly, for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-firefox\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-firefox\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n        platformName: 'Linux'\n        unsafeSsl : 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = FirefoxOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nSimilarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-edge\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-edge\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n        platformName: 'Linux'\n        unsafeSsl : 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = EdgeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nIn case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        nodeMaxSessions: 4\n        unsafeSsl : 'true'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '91.0'\n        unsafeSsl : 'true'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '90.0'\n        unsafeSsl : 'true'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n  graphql-username: base64 encoded value of GraphQL Username\n  graphql-password: base64 encoded value of GraphQL Password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n  - parameter: username\n    name: selenium-grid-secret\n    key: graphql-username\n  - parameter: password\n    name: selenium-grid-secret\n    key: graphql-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl : 'true'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.16/scalers/splunk.md",
    "content": "+++\ntitle = \"Splunk\"\navailability = \"v2.15+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk saved search results.\"\ngo_file = \"splunk_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches).\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: splunk\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"1\"\n      activationValue: \"10\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n**Parameter list:**\n\n- `host` - Search API host and port. Example: `https://localhost:8089`.\n- `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `\"true\"`, `\"false\"`, Default: `\"false\"`, Optional)\n- `targetValue` - Value to reach to start scaling (This value can be a integer or float).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `savedSearchName` - Name of saved search that returns metric data for scaling.\n- `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`.\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication.\n\n> **Note:**\n>\n> `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API.\n\n**Parameter list:**\n\n- `username` - Splunk username authorized to access the search API.\n- `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`.\n- `password` - Password for supplied `username`. Conflicts with `apiToken`.\n\nThe user will need access to the saved search.\n\n### Examples\n\n### Username/password\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### API Token\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # admin\n  apiToken: <base64 encoded api token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: apiToken\n      name: splunk-creds\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### Full example using Splunk deployment\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: splunkconf\ndata:\n  default.yml: |\n    splunk:\n      conf:\n        - key: savedsearches\n          value:\n            directory: /opt/splunk/etc/users/admin/search/local\n            content:\n              my-saved-search-name:\n                action.email.useNSSubject: 1\n                action.webhook.enable_allowlist: 0\n                alert.track: 0\n                cron_schedule: '*/1 * * * *'\n                dispatch.earliest_time: -15m\n                dispatch.latest_time: now\n                display.general.type: statistics\n                display.page.search.tab: statistics\n                display.visualizations.show: 0\n                enableSched: 1\n                request.ui_dispatch_app: search\n                request.ui_dispatch_view: search\n                search: index=_internal | tail | stats count\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: splunk\nspec:\n  ports:\n    - port: 8000\n      targetPort: web\n      name: web-svc\n    - port: 8089\n      targetPort: 8089\n      name: api-svc\n  selector:\n    app: splunk\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: splunk\n  namespace: default\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: splunk\n  template:\n    metadata:\n      labels:\n        app: splunk\n    spec:\n      containers:\n      - name: splunk\n        image: splunk/splunk:9.2\n        ports:\n          - containerPort: 8000\n            name: web\n          - containerPort: 8089\n            name: api\n        env:\n          - name: SPLUNK_START_ARGS\n            value: --accept-license\n          - name: SPLUNK_PASSWORD\n            value: password\n        volumeMounts:\n          - name: splunkconf-volume\n            mountPath: /tmp/defaults\n      volumes:\n        - name: splunkconf-volume\n          configMap:\n            name: splunkconf\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx\n        ports:\n        - containerPort: 8080\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      unsafeSsl: \"true\"\n      targetValue: \"5\"\n      activationValue: \"5\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n"
  },
  {
    "path": "content/docs/2.16/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.16/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.17/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\ndescription = \"How you can start with KEDA as new user\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. \n\nUse the navigation bar on the left to learn more about KEDA's architecture  and how to deploy and use KEDA.\n\n## Where to go\n\nWhat is your involvement with KEDA?\n\n| Role                      | Documentation                                                                                                                                                |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| User                      | This documentation is for users who want to deploy KEDA to scale Kubernetes.                                                                                 |\n| Core Contributor          | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda).                                                         |\n| Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). |\n| Other Contributor         | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers.            |\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optionqal\n```\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n**Regional STS endpoints**\n\n- If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace.  \n- If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses).\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: <SERVICE_ACCOUNT_NAME>\n  namespace: <NAMESPACE>\n  annotations:\n    eks.amazonaws.com/role-arn: <YOUR_IRSA_ROLE_ARN>\n    # Required for regional STS endpoints (e.g. eu-west-1)\n    eks.amazonaws.com/sts-regional-endpoints: \"true\"\n ```\n\n### When do you need regional STS endpoints?\n\nBy default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`).  \nSome regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`).  \n\nIf you see errors like:\n\n```\nAccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n```\n\nwhile your IAM trust policy looks correct, you likely need to enable regional endpoints with:\n\n```yaml\nannotations:\n  eks.amazonaws.com/sts-regional-endpoints: \"true\"\n```\n\n👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nAttach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/bound-service-account-token.md",
    "content": "+++\ntitle = \"Bound service account token\"\n+++\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n## Permissions for KEDA to request service account tokens\n\nBy default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster.\n\nTo allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource.\n\nHere's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account.\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator\n  namespace: my-namespace # Replace with the namespace of the service account\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - my-service-account # Replace with the name of the service account\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding\n  namespace: my-namespace # Replace with the namespace of the service account\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda # Assuming the keda-operator service account is in the keda namespace\n```\n\nAfter applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API.\n\n### Usage in keda-charts\n\nIf you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example:\n\n```yaml\n# values.yaml\npermissions:\n  operator:\n    restrict:\n      serviceAccountTokenCreationRoles:\n      - name: myServiceAccount\n        namespace: myServiceAccountNamespace\n```\n\nThis will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator-myServiceAccount\n  namespace: myServiceAccountNamespace\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - myServiceAccount\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding-myServiceAccount\n  namespace: myServiceAccountNamespace\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator-myServiceAccount\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda\n```\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional.\n    serviceAccount: {path-to-service-account-file}            # Optional.\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.17/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.17/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests.\n\nIt’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup.\n\n## How KEDA works\n\nKEDA monitors external event sources and adjusts your app’s resources based on the demand. Its main components work together to make this possible:\n\n* **KEDA Operator** keeps track of event sources and changes the number of app instances up or down, depending on the demand.\n* **Metrics Server** provides external metrics to Kubernetes’ HPA so it can make scaling decisions.\n* **Scalers** connect to event sources like message queues or databases, pulling data on current usage or load.\n* **Custom Resource Definitions (CRDs)** define how your apps should scale based on triggers like queue length or API request rates.\n\nIn simple terms, KEDA listens to what’s happening outside Kubernetes, fetches the data it needs, and scales your apps accordingly. It’s efficient and integrates well with Kubernetes to handle scaling dynamically.\n\n## KEDA Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\nExternal events, like an increase in queue messages, trigger the **ScaledObject**, which sets the scaling rules. The **Controller** handles the scaling, while the **Metrics Adapter** sends data to the HPA for real-time scaling decisions. **Admission Webhooks** ensure your configuration is correct and won’t cause problems.\n\nThis setup lets Kubernetes adjust resources automatically based on what’s happening outside, keeping things efficient and responsive.\n\n## KEDA Custom Resources (CRDs)\n\nKEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior:\n\n* **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works.\n* **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics.\n* **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials.\n\nThese CRDs give you control over scaling while keeping your apps secure and responsive to demand.\n\n## Scaling Deployments, StatefulSets, and Custom Resources\n\nKEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs.\n\n### Scaling Deployments and StatefulSets\n\nWith KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand.\n\nDeployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand.\n\n### Scaling Custom Resources\n\nKEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically.\n\n### Scaling Jobs\n\nKEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed.\n\n### Authentication\n\nKEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe.\n\n### External Scalers\n\nKEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly.\n\n### Admission Webhooks\n\nKEDA uses admission webhooks to validate your scaling setup. They ensure your configuration is correct, like preventing multiple ScaledObjects from targeting the same app. This reduces errors and makes scaling smoother."
  },
  {
    "path": "content/docs/2.17/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.17/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure-workload | aws | aws-eks | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                              # Required.\n      path: {hashicorp-vault-secret-path}                                 # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure-workload                                            # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n      secretKey: {aws-secret-key}                                         # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Bound service account token(s)\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure-workload | aws | aws-eks | gcp               # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.17/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec).\n> Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.17/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\nThis page describes the deployment scaling behavior of KEDA. \n\n# Specification\n\nSee the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below.\n\n# Scaling objects\n\n## Scaling Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## Scaling Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n# Features\n\n## Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval.\n\nEnabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n## Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledObject` definition:\n\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`.\n\n\n## Scaling Modifiers\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n\n## Activating and Scaling thresholds\n\nKEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Transferring ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disabling validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n### Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n#### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n#### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](./scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.17/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\nThis page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below.\n\n\n# Overview\n\nAs an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n\n# Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nTo reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: false\n```\n\n\n## Example\n\nAn example configuration for autoscaling jobs using a RabbitMQ scaler is given below. \n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.17/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.17/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nKEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization.\n\nUsing **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster.\n\nEach method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment.\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.29 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Prerequisites\n\nTo deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features.\n\nIf you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease.\n\n### Installing\n\n1. To deploy KEDA using Helm, first add the official KEDA Helm repository:\n\n    ```sh\n   helm repo add kedacore https://kedacore.github.io/charts  \n   helm repo update\n    ```\n\n2. Install `keda` by running:\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n    This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods:\n\n    ```sh\n    kubectl get pods -n keda\n    ```\n\nTo deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps:\n\n1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version.\n2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions:\n\n    ```sh\n    kubectl apply -f keda-2.xx.x-crds.yaml\n    ```\n\n    Replace `2.xx.x` with the specific version number you downloaded.\n\nBy deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process.\n> 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues. \n\nDeploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments.\n\n### Uninstalling\n\nTo uninstall KEDA, use the following Helm command:\n\n```sh\nhelm uninstall keda –namespace keda\n```\n\nThis command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run:\n\n```sh\nkubectl delete namespace keda\n```\n\nUninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version.\n\nYou can remove finalizers with the following command:\n\n```sh\nkubectl patch scaledobject <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\nkubectl patch scaledjob <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\n```\n\nReplace \\<*resource-name*\\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster.\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Prerequisites\n\nBefore deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access.\n\nIf you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub.\n\n### Installing\n\nTo deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed.\n\nSearch for \"KEDA\" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace.\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\nUsing Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment.\n\n> 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository:\n> \n> [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator)\n> \n> This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments.\n> \n> For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful:\n>\n> \\- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator.\n> \n> \\- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster.\n> \n> \\- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project.\n\n### Uninstalling\n\nTo uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster.\n\nIf you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks.\n\n## Deploying KEDA using the YAML files {#yaml}\n\n### Prerequisites\n\nBefore deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster.\n\n### Installing\n\nOnce the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3-core.yaml\n```\n\nAlternatively you can download the file and deploy it from the local path:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.17.3.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.17.3-core.yaml\n```\n\nThe `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740).\n\n> 💡 **NOTE:**  If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally:\n>\n> ```sh\n> git clone https://github.com/kedacore/keda && cd keda\n> \n> VERSION=2.17.3 make deploy\n> ```\n>\n> This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization.\n\nAfter applying the YAML, verify the deployment by checking the KEDA namespace:\n\n```sh\nkubectl get pods -n keda\n```\n\nDeploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates.\n\n### Uninstalling\n\nIf you installed KEDA using the released YAML files, you can uninstall it by running the following commands:\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.17.3/keda-2.17.3-core.yaml\n```\n\nIf you downloaded the files locally, uninstall with:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.17.3.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.17.3-core.yaml\n```\n\nFor users who cloned the KEDA GitHub repository, navigate to the cloned directory and use:\n\n```sh\nVERSION=2.17.3 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Prerequisites\n\nBefore deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`).\n\nAdditionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons:\n\n* **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration.\n* **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation.\n\n### Installing\n\nTo install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on.\n\n1. Enable Helm and DNS Add-ons (if not already enabled):\n\n   ```sh\n   microk8s enable dns helm3use\n   ```\n\n2. Add the KEDA Helm Repository:\n\n   ```sh\n   microk8s helm3 repo add kedacore https://kedacore.github.io/charts\n   \n   microk8s helm3 repo update\n   ```\n\n3. Install KEDA Using Helm.\n\n   Deploy KEDA into your MicroK8s cluster by running:\n\n   ```sh\n   microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace\n   ```\n\n4. Verify the Installation.\n\n   Check that KEDA is running by listing the pods in the keda namespace:\n\n   ```sh\n   microk8s kubectl get pods -n keda\n   ```\n\nThis approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development.\n\n### Uninstalling\n\nTo uninstall KEDA from your MicroK8s environment, disable the KEDA add-on:\n\n```sh\nmicrok8s disable keda\n```\n\nThis command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation.\nIf you deployed KEDA using Helm, uninstall it with:\n\n```sh\nmicrok8s helm3 uninstall keda --namespace keda\n```\n\nAfter running these commands, KEDA will be fully removed from your MicroK8s setup.\n\n## Getting Started with KEDA: A Simple Example\n\nTo help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This \"Hello KEDA\" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality.\n\nBefore starting, ensure you have the following:\n\n* **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service.\n* **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster.\n* **KEDA Installed**: KEDA should be installed in your cluster.\n\n### Step 1: Deploy a Sample Application\n\nWe'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server.\n\n1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`:\n\n   ```yaml\n   apiVersion: apps/v1\n   kind: Deployment\n   metadata:\n      name: http-app\n   spec:\n      replicas: 1\n      selector:\n         matchLabels:\n            app: http-app\n      template:\n         metadata:\n            labels:\n               app: http-app\n         spec:\n            containers:\n            - name: http-app\n              image: hashicorp/http-echo\n              args:\n                 - \"-text=Hello, KEDA!\"\n              ports:\n                 - containerPort: 5678\n      ```\n\n2. **Apply the Deployment**: Run the following command to create the deployment:\n\n   ```sh\n   kubectl apply -f deployment.yaml\n   ```\n\n### Step 2: Expose the Application\n\nTo access the application, we'll create a Service.\n\n1. **Create a Service Manifest**: Save the following YAML as service.yaml:\n\n   ```yaml\n   apiVersion: v1\n   kind: Service\n   metadata:\n      name: http-app-service\n   spec:\n      selector:\n         app: http-app\n      ports:\n         - protocol: TCP\n           port: 80\n           targetPort: 5678\n      type: LoadBalancer\n   ```\n\n2. **Apply the Service**: Run the following command to create the service:\n\n   ```sh\n   kubectl apply -f service.yaml\n   ```\n\n3. **Retrieve the External IP**: After a few moments, retrieve the external IP address:\n\n  ```sh\n  kubectl get service http-app-service\n   ```\n\n### Step 3: Create a ScaledObject\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\n\n1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`:\n\n   ```yaml\n   apiVersion: keda.sh/v1alpha1\n   kind: ScaledObject\n   metadata:\n      name: http-app-scaledobject\n   spec:\n      scaleTargetRef:\n         name: http-app\n      minReplicaCount: 1\n      maxReplicaCount: 10\n      triggers:\n         - type: prometheus\n           metadata:\n              serverAddress: http://prometheus-server.default.svc.cluster.local:9090\n              threshold: '5'\n              query: sum(rate(http_requests_total[1m])) \n   ```\n\n   > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed.\n2. **Apply the ScaledObject**: Run the following command to create the ScaledObject:\n\n   ```sh\n   kubectl apply -f scaledobject.yaml   \n   ```\n\n### Step 4: Test the Scaling Behavior\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\nTo observe KEDA's scaling in action:\n\n1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP:\n\n   ```sh\n   hey -z 1m -c 10 http://<EXTERNAL-IP>\n   ```\n\n   Replace `<EXTERNAL-IP>` with the external IP address obtained earlier.\n2. **Monitor Scaling:** Run the following command to watch the scaling behavior:\n\n   ```sh\n   kubectl get pods -w\n   ```\n\n   You should see the number of pods increase as the load increases and decrease when the load subsides.\n\n### Cleanup\n\nAfter completing the exercise, clean up the resources:\n\n   ```sh\n   kubectl delete -f scaledobject.yaml\n   kubectl delete -f service.yaml\n   kubectl delete -f deployment.yaml\n   ```\n\nThis example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events.\n"
  },
  {
    "path": "content/docs/2.17/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.17/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.17/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.17/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n> Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.17/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.17/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance and requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance and requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](../reference/events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.17/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n\n### Cache Miss with Fallback to Direct Client for ScaledObject\n\nWhen validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`:\n```\n--cache-miss-to-direct-client=true\n```\nThis will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API.\n\n\n## Custom Validations using Kubernetes ValidatingAdmissionPolicy\n\n> ⚠️ FEATURE STATE: Kubernetes v1.30 [stable]\n\nKubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).\n\nHere is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10):\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-keda-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"keda.sh\"]\n      apiVersions: [\"v1alpha1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"scaledobjects\"]\n  validations:\n    - expression: \"object.spec.maxReplicaCount <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-keda-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-keda-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```\n\nSince KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas:\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-apps-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"apps\"]\n      apiVersions: [\"v1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"deployments\", \"replicasets\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-hpa-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"autoscaling\"]\n      apiVersions: [\"v2\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"horizontalpodautoscalers\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-apps-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-apps-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-hpa-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-hpa-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```"
  },
  {
    "path": "content/docs/2.17/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                    | Scenario Description                                                                                                        | \n|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| \n| `keda.scaledobject.ready.v1`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails                                                                            |  \n| `keda.scaledobject.removed.v1`| When a ScaledObject is deleted |       \n| `keda.scaledjob.ready.v1`| On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledjob.failed.v1`| If the check validation for a ScaledJob fails                                    \n| `keda.scaledjob.removed.v1`| When a ScaledJob is deleted |  \n| `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created |\n| `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | \n| `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted |  \n| `keda.authentication.clustertriggerauthentication.created.v1`|  On the first time a ClusterTriggerAuthentication is created |\n| `keda.authentication.clustertriggerauthentication.updated.v1`| When a ClusterTriggerAuthentication is updated | \n| `keda.authentication.clustertriggerauthentication.removed.v1`| When a ClusterTriggerAuthentication is deleted |  "
  },
  {
    "path": "content/docs/2.17/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.17 | v1.30 - v1.32 |\n| v2.16 | v1.29 - v1.31 |\n| v2.15 | v1.28 - v1.30 |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.17/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (external metrics only):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.17/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAdditionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources.\n\nExample use case:\n- When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources.\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory.  Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`.\n"
  },
  {
    "path": "content/docs/2.17/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Kubernetes Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)\n"
  },
  {
    "path": "content/docs/2.17/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` | \n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    | \n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |                                                                           |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |                                                                     |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |                                                                    |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |                                                                       |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |                                                           |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |                                                         |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |                                                                       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |                                         |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |                                        |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |                                                              |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |                                                              |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |                                                                                       |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |                                                                                       |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |                                                                                |\n"
  },
  {
    "path": "content/docs/2.17/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_15\" >}}\n"
  },
  {
    "path": "content/docs/2.17/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## gRPC Remote Procedure Calls (gRPC)\n\ngRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.17/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n**eager**\nWhen adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.\n\nFor example, let's assume we configure a ScaledJob in a cluster as below:\n```yaml\n  ###\n  # A job that runs for a minimum of 3 hours.\n  ###\n  pollingInterval: 10 # Optional. Default: 30 seconds\n  maxReplicaCount: 10 # Optional. Default: 100\n  triggers:\n    - type: rabbitmq\n      metadata:\n        queueName: woker_queue\n        hostFromEnv: RABBITMQ_URL\n        mode: QueueLength\n        value: \"1\"\n```\nWe send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.\n\nWith the `default` scaling strategy, we are supposed to see the metrics changes in the following table:\n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 3          |\n\n\nIf we switch to `eager`, the result becomes: \n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 6          |\n\nWe can identify the difference in their final states.\n\n\nYou may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.17/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n    behavior: {kind-of-behavior}                            # Optional. Default: \"static\"\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N.\n\nIf you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly.\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n    behavior: \"static\"                               # Optional. Default: \"static\"\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n## fallback.behavior\n\nThe `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used.\n\n#### `static` behavior\nWhen `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'.\n\n#### `currentReplicas` behavior\nWhen using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'.\n\n#### `currentReplicasIfHigher` behavior\nWhen using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'.\n\n#### `currentReplicasIfLower` behavior\nWhen using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'.\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n### scalingModifiers\n\nIf defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional)\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.17/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.17/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Datastore\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.17/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Optional: ignoreNullValues\n    ignoreNullValues: \"false\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response.  If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional)\n\n> Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload.\n\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n\n> When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n      # Optional. Custom timeout for the HTTP client used in this scaler\n      timeout: \"1000\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n### Links\n\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false \n      # Optional: Require jobs to include specified demands, ignoring any extra ones\n      requireAllDemandsAndIgnoreOthers: false\n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API (Default: `250`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not use demands in your agent scaler then it scales based on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored).\n  - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n  - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list.\n  - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    queueLengthStrategy: all|visibleonly\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      # Optional\n      queueLengthStrategy: \"all\" # or visibleonly. Default: all\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/beanstalkd.md",
    "content": "+++\ntitle = \"Beanstalkd\"\navailability = \"v2.16+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on beanstalkd queues\"\ngo_file = \"beanstalkd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue.\n\n```yaml\ntriggers:\n  - type: beanstalkd\n    metadata:\n      server: beanstalkd.internal-namespace:11300\n      includeDelayed: \"false\"\n      tube: \"default\"\n      activationValue: \"10\"\n      value: \"15\"\n      timeout: \"30\"\n```\n\n**Parameter list:**\n\n- `server` - Address of beanstalkd server `<host>:<port>`. If no port is specified then the scaler will default to `11300`.\n- `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted.\n- `tube` - Name of the tube to scale on.\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set.\n- `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional)\n\n### Authentication Parameters\n\nNo authentication should be needed to connect to the beanstalkd server.\n\n### Example\n\n#### Default tube with activation value\n\nHere the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'default'\n        activationValue: \"10\"\n        value: \"20\"\n```\n\n#### User-created tube with minimum replicas\n\nA minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'scaling-tube'\n        value: \"5\"\n        includeDelayed: \"true\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n- `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional).\n- `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional)\n- `key` - Key path for client authentication. Mandatory if tls enabled. (Optional)\n\n### Example with no TLS auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n\n### Example with TLS auth\n\nSince we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. \n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/cassandra\n            name: temp-cassandra-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-cassandra-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/cassandra\n  name: temp-cassandra-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-cassandra-vol\n  emptyDir:\n    medium: Memory\n```\n\nOnce we have the writable mount path set up for the certificates and keys.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n  tls: enable\n  cert: <cert content | base64encoded>\n  key: <key content | base64encoded>\n  ## Optional parameter ca ##\n  ca: <ca cert content | base64encoded>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n  - parameter: tls\n    name: cassandra-secrets\n    key: tls\n  - parameter: cert\n    name: cassandra-secrets\n    key: cert\n  - parameter: key\n    name: cassandra-secrets\n    key: key\n  ## Optional parameter ca ##\n  - parameter: ca\n    name: cassandra-secrets\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be the same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale your deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do it the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.17/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\nThere are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately.\n\n## Using the Datadog Cluster Agent (Experimental)\n\nWith this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches.\n\n### Deploy the Datadog Cluster Agent with enabled external metrics\n\nFirst, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA).\n\nIf you are using Helm to deploy the Cluster Agent, set:\n\n* `clusterAgent.metricsProvider.enabled` to `true`\n* `clusterAgent.metricsProvider.registerAPIService` to `false`\n* `clusterAgent.metricsProvider.useDatadogMetrics` to `true`\n* `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]`\n\nIf you are using the Datadog Operator, add the following options to your `DatadogAgent` object:\n\n```\napiVersion: datadoghq.com/v2alpha1\nkind: DatadogAgent\nmetadata:\n  name: datadog\nspec:\n  features:\n    externalMetricsServer:\n      enabled: true\n      useDatadogMetrics: true\n      registerAPIService: false\n  override:\n    clusterAgent:\n      env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]\n[...]\n```\n\nNOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later.\n\n### Create a DatadogMetric object for each scaling query\n\nTo use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: \"true\"` annotation, to ensure the Cluster Agent retrieves the query value. Example:\n\n```yaml\napiVersion: datadoghq.com/v1alpha1\nkind: DatadogMetric\nmetadata:\n  annotations:\n    external-metrics.datadoghq.com/always-active: \"true\"\n  name: nginx-hits\nspec:\n  query: sum:nginx.net.request_per_s{kube_deployment:nginx}\n```\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"true\"\n    datadogMetricName: \"nginx-hits\"\n    datadogMetricNamespace: \"default\"\n    targetValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional)\n- `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events.\n- `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events.\n- `targetValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nThe Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below:\n\n**Common to all authentication types**\n- `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional)\n- `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed.\n- `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern.\n- `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional)\n\n**Bearer authentication:**\n- `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: datadog-config\n  namespace: my-project\ndata:\n  datadogNamespace:  # Required: namespace where the Datadog Cluster Agent is deployed\n  datadogMetricsService: # Required: Cluster Agent metrics server service name\n  unsafeSsl: # Optional: set to \"true\" to skip SSL certificate validation\n  authMode:  # Required: authentication mode (bearer)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: datadog-cluster-agent-creds\n  namespace: my-project\nspec:\n   boundServiceAccountToken:\n     - parameter: token\n       serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io\n  configMapTargetRef:\n    - parameter: datadogNamespace\n      name: datadog-config\n      key: datadogNamespace\n    - parameter: unsafeSsl\n      name: datadog-config\n      key: unsafeSsl\n    - parameter: authMode\n      name: datadog-config\n      key: authMode\n    - parameter: datadogMetricsService\n      name: datadog-config\n      key: datadogMetricsService\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx\n  maxReplicaCount: 3\n  minReplicaCount: 1\n  pollingInterval: 60\n  triggers:\n  - type: datadog\n    metadata:\n      useClusterAgentProxy: \"true\"\n      datadogMetricName: \"nginx-hits\"\n      datadogMetricNamespace: \"default\"\n      targetValue: \"2\"\n      type: \"global\"\n    authenticationRef:\n      name: datadog-cluster-agent-creds\n```\n\n## Using the Datadog REST API\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"false\"\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false)\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n### Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../reference/scaledobject-spec/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n### Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n#### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n#### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n### Cases of unexpected metrics value in DataDog API response\n\n#### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n#### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.17/scalers/dynatrace.md",
    "content": "+++\ntitle = \"Dynatrace\"\navailability = \"2.15+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Dynatrace metric data points\"\ngo_file = \"dynatrace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points.\n\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      host: https://dummy-instance.live.dynatrace.com/\n      metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n      # Optional\n      from: now-2d\n      threshold: \"10\"\n      # Optional\n      activationThreshold: \"5\"\n```\n\n**Parameter list:**\n\n- `host` - The Dynatrace instance to query against\n- `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)).\n\n  Some relevant aspects:\n    - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered\n    - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered\n    - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector\n- `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters.\n\n**Authentication:**\n\n- `host` - The Dynatrace instance to query against\n- `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/\n  token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n        from: 'now-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html).\n\nThe trigger always requires the following information, but requires either only searchTemplateName **or** only query:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      query: \"my-query\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `query` - The query to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Examples\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        query: |\n          {\n            \"size\": 0,\n            \"query\": {\n              \"bool\": {\n                \"must\": [\n                  {\n                    \"term\": {\n                      \"service.name\": \"my-application\" }\n                  },\n                  {\n                    \"term\": {\n                      \"service.environment\": \"production\" }\n                  },\n                  {\n                    \"range\": {\n                      \"@timestamp\": {\n                        \"gte\": \"now-2m\",\n                        \"lte\": \"now-1m\"\n                      }\n                    }\n                  }\n                ]\n              }\n            },\n            \"aggs\": {\n              \"transaction_count\": {\n                \"cardinality\": {\n                  \"field\": \"transaction.id\" }\n              }\n            }\n          }\n        valueLocation: \"aggregations.transaction_count.value\"\n        targetValue: \"1000\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n        usernameFromEnv: <admin-user>  # Optional\n        passwordFromEnv: <admin-password> # Optional\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Password based authentication:**\n\n- `username` - Username for authentication. (Optional)\n- `password` - Password for authentication. (Optional)\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on Password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  etcd-username: <your username>\n  etcd-password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-etcd-secrets\n      key: etcd-username\n    - parameter: password\n      name: keda-etcd-secrets\n      key: etcd-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    enableTLS: false\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    filterDuration: '1' # Optional - Default is 2\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    valueIfNull: '0.0' # Optional - Default is \"\"\n    activationValue: \"10.5\" # Optional - Default is 0\n    timeHorizon: \"1m\" # Optional - Default is 2m and with aggregation 5m\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`)\n\n- `valueIfNull` - Value returned if request returns no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    filterDuration: '1' # Optional - Default is 2\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\", defaults to \"false\" (scale on default runner labels)\n      noDefaultLabels: \"{noDefaultLabels}\"\n      # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either \"true\" or \"false\", defaults to \"false\"\n      enableEtags: \"{enableEtags}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabels` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"). (Values: `true`,`false`, Default: \"false\", Optional)\n- `enableEtags` -  Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabelsFromEnv` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\". (Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows,\nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations:\n\n- Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories.\n- Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**Fine-Tuning**\n\nThe current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters.\n\nFor example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly.\n\n*Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).*\n\nAt the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n    unsafeSsl: \"false\" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ).\n- `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional)\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (DEPRECATED: This parameter is deprecated as of KEDA v2.16 in favor of unsafeSsl and will be removed in version v2.18, Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\nExample with Basic Auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n        usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n\nExample with Basic Auth and TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n  cert: <your tls.crt>\n  key: <your tls.key>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n    - parameter: cert\n      name: keda-ibmmq-secret\n      key: cert\n    - parameter: key\n      name: keda-ibmmq-secret\n      key: key\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # DEPRECATED: This parameter is deprecated in favor of trigger.metricType and will be removed in version v2.18; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    format: \"json\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below. Multiple authentication methods can be used simultaneously by providing a comma-separated list in the `authMode` parameter, for example `authMode: \"apiKey,tls\"` enables both API key and TLS certificate authentication in a single request.\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur. This value can be a float.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n> **Notice:**\n> The Stan scaler (NATS Streaming) is DEPRECATED and will be removed in v2.19 - Use scaler [nats-jetstream](./nats-jetstream.md) instead.\n> See also the deprecation notice [here](https://nats-io.gitbook.io/legacy-nats-docs/nats-streaming-server-aka-stan).\n\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n**TLS Authentication**\n\n- `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### Example without any TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with no TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n\n#### Example with TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-stan-secrets\n  namespace: default\ndata:\n  tls: enable\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-stan-secrets\n      key: tls\n    - parameter: ca\n      name: keda-stan-secrets\n      key: ca\n    - parameter: cert\n      name: keda-stan-secrets\n      key: cert\n    - parameter: key\n      name: keda-stan-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"true\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\nAutoscaling trigger based on transaction duration average metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n\nAutoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO\"\n        noDataError: \"true\"\n        threshold: '300'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/nsq.md",
    "content": "+++\ntitle = \"NSQ\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NSQ topic/channel depth.\"\ngo_file = \"nsq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. \n\n```yaml\ntriggers:\n- type: nsq\n  metadata:\n    nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n    topic: \"example_topic\"\n    channel: \"example_channel\"\n    depthThreshold: \"10\"\n    activationDepthThreshold: \"0\"\n    useHttps: \"false\"\n    unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `<hostname>:<port>`.\n- `topic` - Name of the NSQ datastream that the `channel` relates to.\n- `channel` - Name of the channel used to calculate depth.\n- `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional)\n- `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional)\n- `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n> **Notice:**\n> - Since [\"channels are created on first use by subscribing to the named channel\"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0.\n> - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nsq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nsq-consumer-deployment\n  triggers:\n  - type: nsq\n    metadata:\n      nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n      topic: \"example_topic\"\n      channel: \"example_channel\"\n      depthThreshold: \"10\"\n      activationDepthThreshold: \"0\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.17/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for three connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret).\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nIt is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity.  \nMore details and an example are provided down below.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n\n**Azure Access Token authentication:**\n\n#### Prerequisites:\n- The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity).\n- The UAMI should be granted access to the table mentioned in the query performed by KEDA.  \nThis can be achieved by:\n  - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role.\n  - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like  \n  `GRANT ALL ON <TABLE_REF> TO \"<AZURE_UAMI_NAME>\";`.\n\nNext, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process.\n  - `host` - FQDN of the Azure Postgres Flexible Server.\n  - `userName` - Name of the UAMI Azure identity (`<AZURE_UAMI_NAME>`).\n  - `port` - Postgresql port (the default value is `\"5432\"`, please have a look at the `Remarks` down below).\n  - `dbName` - Postgresql Database name.\n  - `sslmode` - SSL policy for communicating with database (the value should be `require`).\n\n\n#### Remarks\n\n- While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port.\n\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-pg-flex-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      authenticationRef:\n        name: azure-pg-flex-auth\n      metadata:\n        host: <AZURE_POSTGRES_FLEX_SERVER_FQDN>\n        port: \"5432\"\n        userName: <UAMI_NAME>\n        dbName: <DB_NAME>\n        sslmode: require\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```"
  },
  {
    "path": "content/docs/2.17/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n    timeout: \"1000\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.17/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string. Required for Azure AD Workload Identity authorization (see bellow)\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n    usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of TriggerAuthentication\n    passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of TriggerAuthentication\n    unsafeSsl: true\n    timeout: \"1000\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain vhost than the trailing slash is required in this case like `http://guest:password@localhost:5672/`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the published rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false` )\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username to use to connect to the broker's management endpoint.\n- `passwordFromEnv` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional / Required if Azure AD Workload Identity authorization is used)\n**Username and Password based authentication:**\n\nThis allows sensitive credentials to be stored and managed separately from the connection string.\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** If username or password are set in TriggerAuthentication or environment variables, they will override any credentials provided in the host.\n\n**TLS authentication:**\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n> Using RabbitMQ host with amqps will require enabling the tls settings and passing the required parameters.\n\n**Azure Workload Identity authentication:**\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use TriggerAuthentication CRD with `podIdentity.provider = azure-workload` and with parameter `workloadIdentityResource` which would hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Only HTTP protocol is supported for AKS Workload Identity currently.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672\n  vhostName: vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: vhostName\n      name: keda-rabbitmq-secret\n      key: vhostName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQP protocol with user/password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://localhost:5672/vhost (no username/password)\n  username: <username> # base64 encoded value of username\n  password: <password> # base64 encoded value of password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: username\n      name: keda-rabbitmq-secret\n      key: username\n    - parameter: password\n      name: keda-rabbitmq-secret\n      key: password \n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"myprimary\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.17/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars, SeleniumHQ\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration with default values represent.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: ''  # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`).\n      browserVersion: '' # Optional.\n      platformName: '' # Optional.\n      unsafeSsl: false # Optional.\n      activationThreshold: 0 # Optional.\n      nodeMaxSessions: 1 # Optional.\n      enableManagedDownloads: true # Optional.\n      capabilities: '' # Optional.\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional).\n- `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional).\n- `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional)\n\n**Trigger Authentication**\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional)\n- `accessToken` - Access token. This is required when `authType` is set a value. (Optional)\n\n### Example\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion`\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nNoted:\n- From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details.\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nWith above script, the request is sent to Grid. Via GraphQL response, it looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 0,\n      \"totalSlots\": 0\n    },\n    \"nodesInfo\": {\n      \"nodes\": []\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nIn Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata.\n\nWhen the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 1,\n      \"totalSlots\": 1\n    },\n    \"nodesInfo\": {\n      \"nodes\": [\n        {\n          \"id\": \"UUID-of-Node\",\n          \"status\": \"UP\",\n          \"sessionCount\": 0,\n          \"maxSession\": 1,\n          \"slotCount\": 1,\n          \"stereotypes\": \"[{\\\"slots\\\": 1, \\\"stereotype\\\": {\\\"browserName\\\": \\\"chrome\\\", \\\"browserVersion\\\": \\\"\\\", \\\"platformName\\\": \\\"Linux\\\"}}]\",\n          \"sessions\": []\n        }\n      ]\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nNow, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in.\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName`\n\nMoreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome-131\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:131.0\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: '131.0'\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-131\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-131\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '131.0'\n        unsafeSsl: 'true'\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '131.0')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n#### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads`\n\nIn image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node\n          - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS\n            value: \"true\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Scaler trigger param configuration should be aligned with Node stereotype.\n        enableManagedDownloads: \"true\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid\noptions.enable_downloads = True\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata with extra `capabilities`\n\nFor an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options\n          - name: SE_NODE_STEREOTYPE_EXTRA\n            value: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536\n        capabilities: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes\noptions.set_capability('myApp:version', 'beta')\noptions.set_capability('myApp:publish', 'public')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Firefox browser\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-firefox\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-firefox\n          image: selenium/node-firefox:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-firefox\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-firefox\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = FirefoxOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Edge browser\n\nSimilarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-edge\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-edge\n          image: selenium/node-edge:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-edge\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-edge\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = EdgeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions`\n\nIn case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n        - name: SE_NODE_OVERRIDE_MAX_SESSIONS\n          value: 'true'\n        - name: SE_NODE_MAX_SESSIONS\n          value: '4'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        nodeMaxSessions: 4\n        unsafeSsl: 'true'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n  graphql-username: base64 encoded value of GraphQL Username\n  graphql-password: base64 encoded value of GraphQL Password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n  - parameter: username\n    name: selenium-grid-secret\n    key: graphql-username\n  - parameter: password\n    name: selenium-grid-secret\n    key: graphql-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/splunk.md",
    "content": "+++\ntitle = \"Splunk\"\navailability = \"v2.15+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk saved search results.\"\ngo_file = \"splunk_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches).\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: splunk\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"1\"\n      activationValue: \"10\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n**Parameter list:**\n\n- `host` - Search API host and port. Example: `https://localhost:8089`.\n- `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `\"true\"`, `\"false\"`, Default: `\"false\"`, Optional)\n- `targetValue` - Value to reach to start scaling (This value can be a integer or float).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `savedSearchName` - Name of saved search that returns metric data for scaling.\n- `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`.\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication.\n\n> **Note:**\n>\n> `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API.\n\n**Parameter list:**\n\n- `username` - Splunk username authorized to access the search API.\n- `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`.\n- `password` - Password for supplied `username`. Conflicts with `apiToken`.\n\nThe user will need access to the saved search.\n\n### Examples\n\n### Username/password\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### API Token\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # admin\n  apiToken: <base64 encoded api token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: apiToken\n      name: splunk-creds\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### Full example using Splunk deployment\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: splunkconf\ndata:\n  default.yml: |\n    splunk:\n      conf:\n        - key: savedsearches\n          value:\n            directory: /opt/splunk/etc/users/admin/search/local\n            content:\n              my-saved-search-name:\n                action.email.useNSSubject: 1\n                action.webhook.enable_allowlist: 0\n                alert.track: 0\n                cron_schedule: '*/1 * * * *'\n                dispatch.earliest_time: -15m\n                dispatch.latest_time: now\n                display.general.type: statistics\n                display.page.search.tab: statistics\n                display.visualizations.show: 0\n                enableSched: 1\n                request.ui_dispatch_app: search\n                request.ui_dispatch_view: search\n                search: index=_internal | tail | stats count\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: splunk\nspec:\n  ports:\n    - port: 8000\n      targetPort: web\n      name: web-svc\n    - port: 8089\n      targetPort: 8089\n      name: api-svc\n  selector:\n    app: splunk\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: splunk\n  namespace: default\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: splunk\n  template:\n    metadata:\n      labels:\n        app: splunk\n    spec:\n      containers:\n      - name: splunk\n        image: splunk/splunk:9.2\n        ports:\n          - containerPort: 8000\n            name: web\n          - containerPort: 8089\n            name: api\n        env:\n          - name: SPLUNK_START_ARGS\n            value: --accept-license\n          - name: SPLUNK_PASSWORD\n            value: password\n        volumeMounts:\n          - name: splunkconf-volume\n            mountPath: /tmp/defaults\n      volumes:\n        - name: splunkconf-volume\n          configMap:\n            name: splunkconf\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx\n        ports:\n        - containerPort: 8080\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      unsafeSsl: \"true\"\n      targetValue: \"5\"\n      activationValue: \"5\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n"
  },
  {
    "path": "content/docs/2.17/scalers/temporal.md",
    "content": "+++\ntitle = \"Temporal\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Temporal task queue.\"\ngo_file = \"temporal_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `temporal` trigger that scales based on a Temporal task queue.\n\n```yaml\ntriggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n      queueTypes: workflow # optional\n      buildId: 1.0.0 # optional\n      selectAllActive: \"false\" # optional\n      selectUnversioned: \"false\" # optional\n      minConnectTimeout: \"5\" # optional\n      unsafeSsl: \"false\" # optional\n```\n\n**Parameter list:**\n\n- `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `<hostname>:<port>`. (Required)\n- `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional)\n- `namespace` - The namespace of the temporal service. (Default:`default`, Optional)\n- `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found  [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional)\n- `taskQueue` - This parameter specifies the task queue name. (Required)\n- `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional)\n- `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional)\n- `selectAllActive` - Include all active versions (Default:`false`, Optional)\n- `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional)\n- `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional)\n- `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional)\n\n> 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero.\n  This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog.\n  Consequently, scaling to zero could result in undesirable behavior,\n  such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA).\n  By fine-tuning the configurations, you can prevent premature scaling to zero,\n  ensuring that resources remain available for in-flight tasks or workloads with minimal throughput.\n\n\n**Authentication Parameters:**\n\nTemporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication:\n\n- `apiKey` - API key for authentication with temporal cloud. (Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: temporal-secret\n  namespace: default\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-temporal\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: apiKey\n    name: temporal-secret\n    key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: workload-scaledobject\n  pollingInterval: 5\n  cooldownPeriod:  10\n  minReplicaCount: 0\n  maxReplicaCount: 5\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 10\n  triggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n    authenticationRef:\n      name: keda-trigger-auth-temporal\n```\n"
  },
  {
    "path": "content/docs/2.17/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.17/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.18/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\ndescription = \"How you can start with KEDA as new user\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. \n\nUse the navigation bar on the left to learn more about KEDA's architecture  and how to deploy and use KEDA.\n\n## Where to go\n\nWhat is your involvement with KEDA?\n\n| Role                      | Documentation                                                                                                                                                |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| User                      | This documentation is for users who want to deploy KEDA to scale Kubernetes.                                                                                 |\n| Core Contributor          | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda).                                                         |\n| Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). |\n| Other Contributor         | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers.            |\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optionqal\n```\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n**Regional STS endpoints**\n\n- If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace.  \n- If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses).\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: <SERVICE_ACCOUNT_NAME>\n  namespace: <NAMESPACE>\n  annotations:\n    eks.amazonaws.com/role-arn: <YOUR_IRSA_ROLE_ARN>\n    # Required for regional STS endpoints (e.g. eu-west-1)\n    eks.amazonaws.com/sts-regional-endpoints: \"true\"\n ```\n\n### When do you need regional STS endpoints?\n\nBy default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`).  \nSome regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`).  \n\nIf you see errors like:\n\n```\nAccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n```\n\nwhile your IAM trust policy looks correct, you likely need to enable regional endpoints with:\n\n```yaml\nannotations:\n  eks.amazonaws.com/sts-regional-endpoints: \"true\"\n```\n\n👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nAttach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/bound-service-account-token.md",
    "content": "+++\ntitle = \"Bound service account token\"\n+++\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n## Permissions for KEDA to request service account tokens\n\nBy default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster.\n\nTo allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource.\n\nHere's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account.\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator\n  namespace: my-namespace # Replace with the namespace of the service account\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - my-service-account # Replace with the name of the service account\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding\n  namespace: my-namespace # Replace with the namespace of the service account\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda # Assuming the keda-operator service account is in the keda namespace\n```\n\nAfter applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API.\n\n### Usage in keda-charts\n\nIf you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example:\n\n```yaml\n# values.yaml\npermissions:\n  operator:\n    restrict:\n      serviceAccountTokenCreationRoles:\n      - name: myServiceAccount\n        namespace: myServiceAccountNamespace\n```\n\nThis will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator-myServiceAccount\n  namespace: myServiceAccountNamespace\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - myServiceAccount\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding-myServiceAccount\n  namespace: myServiceAccountNamespace\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator-myServiceAccount\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda\n```\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method. There's multiple methods for authentication; For kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) or provide the serviceAccountName that can authenticate to kubernetes in the namespace of the ScaledObject/ScaledJob resource (usually `default`). If using serviceAccountName make sure to grant KEDA Operator `create serviceaccounts/token` permissions. This is set in the helm chart via `permissions.operator.restrict.allowAllServiceAccountTokenCreation=true` For token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional. Authenticate to vault via a supplied token\n    serviceAccount: {path-to-service-account-file}            # Optional. Authenticate to vault via JWT token in keda operator pod\n    serviceAccountName: {service-account-name-for-auth}       # Optional. Requires serviceaccounts/token create permissions. Authenticate to vault via JWT token from service account in ScaledObject/ScaledJob's namespace\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.18/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.18/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests.\n\nIt’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup.\n\n## How KEDA works\n\nKEDA monitors external event sources and adjusts your app’s resources based on the demand. Its main components work together to make this possible:\n\n* **KEDA Operator** keeps track of event sources and changes the number of app instances up or down, depending on the demand.\n* **Metrics Server** provides external metrics to Kubernetes’ HPA so it can make scaling decisions.\n* **Scalers** connect to event sources like message queues or databases, pulling data on current usage or load.\n* **Custom Resource Definitions (CRDs)** define how your apps should scale based on triggers like queue length or API request rates.\n\nIn simple terms, KEDA listens to what’s happening outside Kubernetes, fetches the data it needs, and scales your apps accordingly. It’s efficient and integrates well with Kubernetes to handle scaling dynamically.\n\n## KEDA Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\nExternal events, like an increase in queue messages, trigger the **ScaledObject**, which sets the scaling rules. The **Controller** handles the scaling, while the **Metrics Adapter** sends data to the HPA for real-time scaling decisions. **Admission Webhooks** ensure your configuration is correct and won’t cause problems.\n\nThis setup lets Kubernetes adjust resources automatically based on what’s happening outside, keeping things efficient and responsive.\n\n## KEDA Custom Resources (CRDs)\n\nKEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior:\n\n* **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works.\n* **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics.\n* **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials.\n\nThese CRDs give you control over scaling while keeping your apps secure and responsive to demand.\n\n## Scaling Deployments, StatefulSets, and Custom Resources\n\nKEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs.\n\n### Scaling Deployments and StatefulSets\n\nWith KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand.\n\nDeployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand.\n\n### Scaling Custom Resources\n\nKEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically.\n\n### Scaling Jobs\n\nKEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed.\n\n### Authentication\n\nKEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe.\n\n### External Scalers\n\nKEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly.\n\n### Consuming Raw Scaler Metrics Externally\n\nKEDA also allows consuming the internal metrics (coming from internal or external scalers) to interested 3rd parties. This feature is exposed using gRPC server stream API and needs to be first enabled by setting `RAW_METRICS_GRPC_PROTOCOL` to \"`enabled`\". Then one can subscribe to a metric identified by ScaledObject/ScaledJob name, namespace and trigger name using any gRPC client (example with [grpcurl](https://github.com/kedacore/keda/pull/7093#issuecomment-3333530716)).\n\nYou can control when raw metrics are sent using the `RAW_METRICS_MODE` environment variable:\n\n* `all` or `\"\"` (empty): Sends all raw metrics, both when the metrics server requests them (HPA) and during the regular polling interval of each ScaledObject or ScaledJob. This is the default behavior.\n* `hpa`: Sends raw metrics only when the Kubernetes metrics server explicitly requests metrics for a ScaledObject. This means metrics are sent in response to HPA queries, not on a regular schedule.\n* `pollinginterval`: Sends raw metrics only during the polling interval of each ScaledObject or ScaledJob. In this mode, metrics are pushed out at each polling cycle, regardless of HPA requests.\n* Any unknown value will default to the `all` mode.\n\n### Admission Webhooks\n\nKEDA uses admission webhooks to validate your scaling setup. They ensure your configuration is correct, like preventing multiple ScaledObjects from targeting the same app. This reduces errors and makes scaling smoother.\n"
  },
  {
    "path": "content/docs/2.18/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.18/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure-workload | aws | aws-eks | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                              # Required.\n      path: {hashicorp-vault-secret-path}                                 # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure-workload                                            # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n      secretKey: {aws-secret-key}                                         # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Bound service account token(s)\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure-workload | aws | aws-eks | gcp               # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.18/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec).\n> Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.18/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\nThis page describes the deployment scaling behavior of KEDA. \n\n# Specification\n\nSee the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below.\n\n# Scaling objects\n\n## Scaling Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## Scaling Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n# Features\n\n## Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval.\n\nEnabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n## Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledObject` definition:\n\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`.\n\nAdditionally, we provide the ability to temporarily pause scale in on a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-scale-in: \"true\"\n```\n\nWhen the annotation is set, KEDA will update the generated HPA to disable scale in (via setting the HPA's Scale Down Select Policy to Disabled) and if the service has scale to zero configured, will block scale to zero. When the annotation is unset, the scale down behavior on the HPA will be restored to its original configuration and, if configured, scale to zero will be unblocked. \n\nConversely, we provide the ability to temporarily pause scale out on a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-scale-out: \"true\"\n```\n\nWhen the annotation is set, KEDA will update the generated HPA to disable scale out (via setting the HPA's Scale Up Select Policy to Disabled) and if the service has scale to zero configured, will block scale from zero. When the annotation is unset, the scale up behavior on the HPA will be restored to its original configuration and, if configured, scale up from zero will be unblocked. \n\nIf you want disable scaling in both directions, we recommend you use the `autoscaling.keda.sh/paused` as that will stop the scale loop and paused queries against the ScaledObject's configured scaler.\n\n## Scaling Modifiers\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n\n## Activating and Scaling thresholds\n\nKEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Forcing Activation\n\nWe provide the ability to temporarily force the activation of a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/force-activation: \"true\"\n```\n\nWhen the annotation is set, KEDA will treat all configured scalers as active. If the scalers were previously not active, KEDA will scale the service up from 0.\n\nWhen the annotation is subsequently unset, the state of the scaler activation will revert to being computed from the state of the scaler metrics.\n\n## Transferring ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disabling validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n### Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n#### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n#### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](./scaling-jobs).\n\n## Excluding labels from being propagated to the HPA\n\nYou can exclude specific labels from being propagated to the generated HPA object by using the `scaledobject.keda.sh/hpa-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded.\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/hpa-excluded-labels: \"foo.bar/environment,foo.bar/version\"\n  labels:\n    team: backend\n    foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5\n    foo.bar/version: \"1\"\n"
  },
  {
    "path": "content/docs/2.18/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\nThis page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below.\n\n\n# Overview\n\nAs an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n\n# Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nTo reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: false\n```\n\n\n## Example\n\nAn example configuration for autoscaling jobs using a RabbitMQ scaler is given below. \n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n# Excluding labels from being propagated to the Job\n\nYou can exclude specific labels from being propagated to the generated Job object by using the `scaledjob.keda.sh/job-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded.\n\n```yaml\nmetadata:\n  annotations:\n    scaledjob.keda.sh/job-excluded-labels: \"foo.bar/environment,foo.bar/version\"\n  labels:\n    team: backend\n    foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5\n    foo.bar/version: \"1\"\n"
  },
  {
    "path": "content/docs/2.18/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.18/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nKEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization.\n\nUsing **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster.\n\nEach method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment.\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.30 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Prerequisites\n\nTo deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features.\n\nIf you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease.\n\n### Installing\n\n1. To deploy KEDA using Helm, first add the official KEDA Helm repository:\n\n    ```sh\n   helm repo add kedacore https://kedacore.github.io/charts  \n   helm repo update\n    ```\n\n2. Install `keda` by running:\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n    This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods:\n\n    ```sh\n    kubectl get pods -n keda\n    ```\n\nTo deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps:\n\n1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version.\n2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions:\n\n    ```sh\n    kubectl apply -f keda-2.xx.x-crds.yaml\n    ```\n\n    Replace `2.xx.x` with the specific version number you downloaded.\n\nBy deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process.\n> 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues.\n\nDeploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments.\n\n### Uninstalling\n\nTo uninstall KEDA, use the following Helm command:\n\n```sh\nhelm uninstall keda –namespace keda\n```\n\nThis command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run:\n\n```sh\nkubectl delete namespace keda\n```\n\nUninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version.\n\nYou can remove finalizers with the following command:\n\n```sh\nkubectl patch scaledobject <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\nkubectl patch scaledjob <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\n```\n\nReplace \\<*resource-name*\\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster.\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Prerequisites\n\nBefore deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access.\n\nIf you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub.\n\n### Installing\n\nTo deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed.\n\nSearch for \"KEDA\" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace.\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\nUsing Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment.\n\n> 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository:\n> \n> [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator)\n> \n> This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments.\n> \n> For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful:\n>\n> \\- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator.\n> \n> \\- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster.\n> \n> \\- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project.\n\n### Uninstalling\n\nTo uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster.\n\nIf you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks.\n\n## Deploying KEDA using the YAML files {#yaml}\n\n### Prerequisites\n\nBefore deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster.\n\n### Installing\n\nOnce the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3-core.yaml\n```\n\nAlternatively you can download the file and deploy it from the local path:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.18.3.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.18.3-core.yaml\n```\n\nThe `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740).\n\n> 💡 **NOTE:**  If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally:\n>\n> ```sh\n> git clone https://github.com/kedacore/keda && cd keda\n> \n> VERSION=2.18.3 make deploy\n> ```\n>\n> This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization.\n\nAfter applying the YAML, verify the deployment by checking the KEDA namespace:\n\n```sh\nkubectl get pods -n keda\n```\n\nDeploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates.\n\n### Uninstalling\n\nIf you installed KEDA using the released YAML files, you can uninstall it by running the following commands:\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.18.3/keda-2.18.3-core.yaml\n```\n\nIf you downloaded the files locally, uninstall with:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.18.3.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.18.3-core.yaml\n```\n\nFor users who cloned the KEDA GitHub repository, navigate to the cloned directory and use:\n\n```sh\nVERSION=2.18.3 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Prerequisites\n\nBefore deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`).\n\nAdditionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons:\n\n* **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration.\n* **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation.\n\n### Installing\n\nTo install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on.\n\n1. Enable Helm and DNS Add-ons (if not already enabled):\n\n   ```sh\n   microk8s enable dns helm3use\n   ```\n\n2. Add the KEDA Helm Repository:\n\n   ```sh\n   microk8s helm3 repo add kedacore https://kedacore.github.io/charts\n   \n   microk8s helm3 repo update\n   ```\n\n3. Install KEDA Using Helm.\n\n   Deploy KEDA into your MicroK8s cluster by running:\n\n   ```sh\n   microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace\n   ```\n\n4. Verify the Installation.\n\n   Check that KEDA is running by listing the pods in the keda namespace:\n\n   ```sh\n   microk8s kubectl get pods -n keda\n   ```\n\nThis approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development.\n\n### Uninstalling\n\nTo uninstall KEDA from your MicroK8s environment, disable the KEDA add-on:\n\n```sh\nmicrok8s disable keda\n```\n\nThis command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation.\nIf you deployed KEDA using Helm, uninstall it with:\n\n```sh\nmicrok8s helm3 uninstall keda --namespace keda\n```\n\nAfter running these commands, KEDA will be fully removed from your MicroK8s setup.\n\n## Getting Started with KEDA: A Simple Example\n\nTo help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This \"Hello KEDA\" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality.\n\nBefore starting, ensure you have the following:\n\n* **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service.\n* **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster.\n* **KEDA Installed**: KEDA should be installed in your cluster.\n\n### Step 1: Deploy a Sample Application\n\nWe'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server.\n\n1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`:\n\n   ```yaml\n   apiVersion: apps/v1\n   kind: Deployment\n   metadata:\n      name: http-app\n   spec:\n      replicas: 1\n      selector:\n         matchLabels:\n            app: http-app\n      template:\n         metadata:\n            labels:\n               app: http-app\n         spec:\n            containers:\n            - name: http-app\n              image: hashicorp/http-echo\n              args:\n                 - \"-text=Hello, KEDA!\"\n              ports:\n                 - containerPort: 5678\n      ```\n\n2. **Apply the Deployment**: Run the following command to create the deployment:\n\n   ```sh\n   kubectl apply -f deployment.yaml\n   ```\n\n### Step 2: Expose the Application\n\nTo access the application, we'll create a Service.\n\n1. **Create a Service Manifest**: Save the following YAML as `service.yaml`:\n\n   ```yaml\n   apiVersion: v1\n   kind: Service\n   metadata:\n      name: http-app-service\n   spec:\n      selector:\n         app: http-app\n      ports:\n         - protocol: TCP\n           port: 80\n           targetPort: 5678\n      type: LoadBalancer\n   ```\n\n2. **Apply the Service**: Run the following command to create the service:\n\n   ```sh\n   kubectl apply -f service.yaml\n   ```\n\n3. **Retrieve the External IP**: After a few moments, retrieve the external IP address:\n\n   ```sh\n   kubectl get service http-app-service\n   ```\n\n### Step 3: Create a ScaledObject\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\n\n1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`:\n\n   ```yaml\n   apiVersion: keda.sh/v1alpha1\n   kind: ScaledObject\n   metadata:\n      name: http-app-scaledobject\n   spec:\n      scaleTargetRef:\n         name: http-app\n      minReplicaCount: 1\n      maxReplicaCount: 10\n      triggers:\n         - type: prometheus\n           metadata:\n              serverAddress: http://prometheus-server.default.svc.cluster.local:9090\n              threshold: '5'\n              query: sum(rate(http_requests_total[1m])) \n   ```\n\n   > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed.\n2. **Apply the ScaledObject**: Run the following command to create the ScaledObject:\n\n   ```sh\n   kubectl apply -f scaledobject.yaml   \n   ```\n\n### Step 4: Test the Scaling Behavior\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\nTo observe KEDA's scaling in action:\n\n1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP:\n\n   ```sh\n   hey -z 1m -c 10 http://<EXTERNAL-IP>\n   ```\n\n   Replace `<EXTERNAL-IP>` with the external IP address obtained earlier.\n2. **Monitor Scaling:** Run the following command to watch the scaling behavior:\n\n   ```sh\n   kubectl get pods -w\n   ```\n\n   You should see the number of pods increase as the load increases and decrease when the load subsides.\n\n### Cleanup\n\nAfter completing the exercise, clean up the resources:\n\n   ```sh\n   kubectl delete -f scaledobject.yaml\n   kubectl delete -f service.yaml\n   kubectl delete -f deployment.yaml\n   ```\n\nThis example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events.\n"
  },
  {
    "path": "content/docs/2.18/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.18/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.18/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.18/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n> Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.18/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.18/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance and requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance and requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](../reference/events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.18/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n\n### Cache Miss with Fallback to Direct Client for ScaledObject\n\nWhen validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`:\n```\n--cache-miss-to-direct-client=true\n```\nThis will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API.\n\n\n## Custom Validations using Kubernetes ValidatingAdmissionPolicy\n\n> ⚠️ FEATURE STATE: Kubernetes v1.30 [stable]\n\nKubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).\n\nHere is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10):\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-keda-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"keda.sh\"]\n      apiVersions: [\"v1alpha1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"scaledobjects\"]\n  validations:\n    - expression: \"object.spec.maxReplicaCount <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-keda-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-keda-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```\n\nSince KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas:\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-apps-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"apps\"]\n      apiVersions: [\"v1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"deployments\", \"replicasets\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-hpa-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"autoscaling\"]\n      apiVersions: [\"v2\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"horizontalpodautoscalers\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-apps-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-apps-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-hpa-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-hpa-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```"
  },
  {
    "path": "content/docs/2.18/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 Event will be emitted to both Kubernetes Events and CloudEvents Destination if CloudEventSource resource is created.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                    | Scenario Description                                                                                                        | \n|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------| \n| `keda.scaledobject.ready.v1`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledobject.failed.v1` | If the check validation for a ScaledObject fails                                                                            |  \n| `keda.scaledobject.removed.v1`| When a ScaledObject is deleted |       \n| `keda.scaledjob.ready.v1`| On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False` |  \n| `keda.scaledjob.failed.v1`| If the check validation for a ScaledJob fails                                    \n| `keda.scaledjob.removed.v1`| When a ScaledJob is deleted |  \n| `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created |\n| `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated | \n| `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted |  \n| `keda.authentication.clustertriggerauthentication.created.v1`|  On the first time a ClusterTriggerAuthentication is created |\n| `keda.authentication.clustertriggerauthentication.updated.v1`| When a ClusterTriggerAuthentication is updated | \n| `keda.authentication.clustertriggerauthentication.removed.v1`| When a ClusterTriggerAuthentication is deleted |  "
  },
  {
    "path": "content/docs/2.18/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.19 | TBD           |\n| v2.18 | v1.31 - v1.33 |\n| v2.17 | v1.30 - v1.32 |\n| v2.16 | v1.29 - v1.31 |\n| v2.15 | v1.28 - v1.30 |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n\n## Logs\n\nKEDA uses zap to emit logs. The following flags can be used to configure logging behavior in both the metrics-apiserver and operator:\n\n- zap-encoder: Zap log encoding (one of `json` or `console`). Default is `console`\n- zap-log-level: Zap Level to configure the verbosity of logging. Can be one of `debug`, `info`, `error`,\n  or any integer value > 0 which corresponds to custom debug levels of increasing verbosity\"). Default is `info`.\n- zap-time-encoding: Zap time encoding (one of `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano`),\n  Defaults is `rfc3339`.\n"
  },
  {
    "path": "content/docs/2.18/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (external metrics only):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.18/operate/schema.md",
    "content": "+++\ntitle = \"Schema\"\ndescription = \"Specification & generation of KEDA scalers' schema\"\nweight = 100\n+++\n\n## Scaler Schema\n\nKEDA provides a separate scaler's schema for third-party usage ([scalers-metadata-schema.yaml](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.yaml)/[scalers-metadata-schema.json](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.json)). The schema file will keep updating according to the scaler's refactor.\n\n*Notice: The schema file still lacks some of the scalers. It will be completed once all scalers are refactored to use the new declarative scaler config.\n\n## Specification\n\nHere is a the schema of the scalers:\n\n```\nkedaVersion: main \nschemaVersion: 1\nscalers:\n    - type: activemq\n      parameters:\n        - name: managementEndpoint\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: destinationName\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: brokerName\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: username\n          type: string\n          metadataVariableReadable: true\n          envVariableReadable: true\n          triggerAuthenticationVariableReadable: true\n        - name: password\n          type: string\n          metadataVariableReadable: true\n          envVariableReadable: true\n          triggerAuthenticationVariableReadable: true\n        - name: corsHeader\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: restAPITemplate\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: targetQueueSize\n          type: string\n          default: \"10\"\n          metadataVariableReadable: true\n        - name: activationTargetQueueSize\n          type: string\n          default: \"0\"\n          metadataVariableReadable: true\n    - type: apache-kafka\n      parameters:\n        - name: bootstrapServers\n        ...\n\n```\n\n**Metadata field's property detail:**\n| Property  | Description \n|--------------|------------\n| name         | the name of the field\n| type         | type is the variable type of the field\n| optional     | optional is a boolean that indicates if the field is optional\n| default      | default is the default value of the field \n| allowedValue | allowedValue is a list of allowed values for the field\n| deprecated   | deprecated is a string that indicates if the field is deprecated\n| deprecatedAnnounce | deprecatedAnnounce is a string that indicates the deprecation message\n| separator | separator is the symbol that separates the value of the field if the value is a list string\n| exclusiveSet | exclusiveSet is a list of fields that are exclusive with the field\n| rangeSeparator | rangeSeparator is the symbol that indicates the range of the field\n| metadataVariableReadable | metadataVariableReadable is a boolean that indicates if the field can be read from the environment\n| envVariableReadable | envVariableReadable is a boolean that indicates if the field can be read from the environment\n| triggerAuthenticationVariableReadable | triggerAuthenticationVariableReadable is a boolean that indicates if the field can be read from the trigger authentication\n\n## Generation\n\nThere are two ways to generate scaler schemas:\n\n1. Run the GO file in the schema folder directly\n```\ngo run schema/generate_scaler_schema.go\nparameters:\n  --keda-version string                Set the version of current KEDA in schema. (default \"1.0\")\n  --kubeconfig string                  Paths to a kubeconfig. Only required if out-of-cluster.\n  --output-file-path string            scaler-metadata-schemas.yaml output file path. (default \"./\")\n  --scalers-builder-file buildScaler   The file that exists buildScaler func. (default \"../pkg/scaling/scalers_builder.go\")\n  --scalers-files-dir string           The directory that exists all scalers' files. (default \"../pkg/scalers\")\n  --specify-scaler string              Specify scaler name.\n```\n\n2. Use makefile\n```\nmake  generate-scaler-schemas\nenv variables:\n    OUTPUT_FILE_PATH          scaler-metadata-schemas.yaml output file path. (default \"./\")\n    SCALERS_BUILDER_FILE   The file that exists buildScaler func. (default \"../pkg/scaling/scalers_builder.go\")\n    SCALERS_FILES_DIR           The directory that exists all scalers' files. (default \"../pkg/scalers\")\n```\n\n SCALERS_BUILDER_FILE ?= \"pkg/scaling/scalers_builder.go\" \n SCALERS_FILES_DIR ?= \"pkg/scalers\" \n OUTPUT_FILE_PATH ?= \"schema/\"\n"
  },
  {
    "path": "content/docs/2.18/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAdditionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources.\n\nExample use case:\n- When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources.\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory.  Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`.\n"
  },
  {
    "path": "content/docs/2.18/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Kubernetes Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)\n"
  },
  {
    "path": "content/docs/2.18/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScalerInfo`                      | `Normal`  | When a Scaler contains deprecated field                                                                                     |\n| `KEDAScalerInfo`                      | `Warning` | When a Scaler contains unexpected parameter (disabled by default, enable with `KEDA_CHECK_UNEXPECTED_SCALERS_PARAMS`)       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.18/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_15\" >}}\n"
  },
  {
    "path": "content/docs/2.18/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## gRPC Remote Procedure Calls (gRPC)\n\ngRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.18/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n**eager**\nWhen adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.\n\nFor example, let's assume we configure a ScaledJob in a cluster as below:\n```yaml\n  ###\n  # A job that runs for a minimum of 3 hours.\n  ###\n  pollingInterval: 10 # Optional. Default: 30 seconds\n  maxReplicaCount: 10 # Optional. Default: 100\n  triggers:\n    - type: rabbitmq\n      metadata:\n        queueName: woker_queue\n        hostFromEnv: RABBITMQ_URL\n        mode: QueueLength\n        value: \"1\"\n```\nWe send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.\n\nWith the `default` scaling strategy, we are supposed to see the metrics changes in the following table:\n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 3          |\n\n\nIf we switch to `eager`, the result becomes: \n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 6          |\n\nWe can identify the difference in their final states.\n\n\nYou may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.18/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n    behavior: {kind-of-behavior}                            # Optional. Default: \"static\"\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N.\n\nIf you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly.\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n    behavior: \"static\"                               # Optional. Default: \"static\"\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nFallback is supported for all triggers of both `Value` and `AverageValue` metric types, except CPU & memory triggers. It's also only supported by `ScaledObjects`, not `ScaledJobs`.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula for `AverageValue` metrics:\n```\ntarget metric value * fallback replicas\n```\nFor `Value` metrics it's using the formula:\n```\ntarget metric value * fallback replicas / current ready replicas\n```\n\nThese formulas offset the HPA's calculations and will cause it to scale the deployment to the specified number of fallback replicas.\n\n## fallback.behavior\n\nThe `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used.\n\n#### `static` behavior\nWhen `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'.\n\n#### `currentReplicas` behavior\nWhen using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'.\n\n#### `currentReplicasIfHigher` behavior\nWhen using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'.\n\n#### `currentReplicasIfLower` behavior\nWhen using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'.\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n          tolerance: 0.1                          # requires Kubernetes v1.33 or newer and feature gate \"HPAConfigurableTolerance\"\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n#### horizontalPodAutoscalerConfig.behavior tolerance\n\nAs of Kubernetes v1.34 the `tolerance` field can be specified under the HPA behavior policy `scaleUp` and `scaleDown` sections. The field applies a tolerance thresholds for scaling decisions, allowing you to specify different behavior for scale-up and scale-down operations. This field was in alpha release under Kubernetes v1.33, which can be enabled through the Kubernetes `HPAConfigurableTolerance` feature gate. As of Kubernetes v1.34, this field has graduated to beta release and is specifiable by default.\n\n\n### scalingModifiers\n\nIf defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional).\n\nThere is one important exception to the activation target for scaling modifiers and that is [external push scalers](../concepts/external-scalers). These scalers can implement `StreamIsActive` gRPC method which pushes activation status to KEDA directly, regardless of what the metric value and activation target is.\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.18/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.18/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    ensureEvenDistributionOfPartitions: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### New `ensureEvenDistributionOfPartitions` property support\n\nWhen scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to.\n\nConsider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution.\n\nBelow are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default.\n\n- For lag between `1 -> 10` we would be running `1` consumer\n- For lag between `11 -> 20` we would be running `2` consumer\n- For lag between `21 -> 50` we would be running `5` consumers\n- For lag higher than `51` we would be running `10` consumers\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    ensureEvenDistributionOfPartitions: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### New `ensureEvenDistributionOfPartitions` property support\n\nWhen scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to.\n\nConsider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution.\n\nBelow are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default.\n\n- For lag between `1 -> 10` we would be running `1` consumer\n- For lag between `11 -> 20` we would be running `2` consumer\n- For lag between `21 -> 50` we would be running `5` consumers\n- For lag higher than `51` we would be running `10` consumers\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Datastore\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n**TLS authentication:**\n\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - Password for the client certificate private key. (Optional, Required when `key` is encrypted)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```\n\n### Example with TLS (HTTPS with self-signed certificates)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8443\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        unsafeSsl: \"true\"  # Skip certificate validation for self-signed certificates\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```\n\n### Example with mutual TLS (client certificates)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis-tls\n  namespace: kedartemis\ntype: Opaque\ndata:\n  artemis-ca: \"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=\"  # Base64 encoded CA certificate\n  artemis-cert: \"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=\"  # Base64 encoded client certificate\n  artemis-key: \"LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi4uLgo=\"  # Base64 encoded client private key\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis-tls\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: ca\n      name: kedartemis-tls\n      key: artemis-ca\n    - parameter: cert\n      name: kedartemis-tls\n      key: artemis-cert\n    - parameter: key\n      name: kedartemis-tls\n      key: artemis-key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8443\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n      authenticationRef:\n        name: trigger-auth-kedartemis-tls\n```"
  },
  {
    "path": "content/docs/2.18/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Optional: ignoreNullValues\n    ignoreNullValues: \"false\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). Supports all CloudWatch statistics including percentiles (e.g., `p95`, `p50`) and trimmed means (e.g., `tm99`, `tm95`). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response.  If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional)\n\n> Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload.\n\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n\n> When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n      # Optional. Custom timeout for the HTTP client used in this scaler\n      timeout: \"1000\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n### Links\n\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false\n      # Optional: Require jobs to include specified demands, ignoring any extra ones\n      requireAllDemandsAndIgnoreOthers: false\n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n      # Optional: Whether to only fetch unfinished jobs from the API (default: false)\n      fetchUnfinishedJobsOnly: false\n      # Optional: Property to enable case-insensitive comparison of pipeline job demands (default: false)\n      caseInsensitiveDemandsProcessing: false\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\". Mutually exclusive with `jobsToFetch`.\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API. Mutually exclusive with `parent` and `fetchUnfinishedJobsOnly`. (Default: `250`, Optional)\n- `fetchUnfinishedJobsOnly` - Whether to fetch only unfinished jobs from the Azure Pipeline API. Normally both finished, running and pending jobs are returned by the API. When this parameter is set to `true`, the API call is modified so that only running and pending jobs are returned from the API, which reduces the amount of returned jobs considerably. Mutually exclusive with `jobsToFetch`. (Default: `false`, Optional)\n- `caseInsensitiveDemandsProcessing` - Property to enable case-insensitive comparison of pipeline job demands. When this parameter is set to `true`, the demands check is case-insensitive. (Default: `false`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not use demands in your agent scaler then it scales based on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored).\n  - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n  - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list.\n  - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands:\n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\nHowever, as this an undocumented API, it possesses some unique quirks when calling it with different query parameters. For example, if the `$top` query parameter is given, the format of the returned JSON is changed in such a way that it is no longer possible for the scaler to find the matched agents; making it impossible to use with the `parent` property from the trigger metadata. Therefore making `jobsToFetch` mutually exclusive with `parent` in the trigger metadata.\n\nAdditionally, the `$top` query parameter takes precedence over some other parameters like `completedRequestCount`. If the `$top` query parameter is given, finished jobs are included in the response even if `completedRequestCount=0` is given, although `completedRequestCount=0` would indicate that only pending and running jobs should be returned. Thus, `jobsToFetch` is also mutually exclusive with `fetchUnfinishedJobsOnly` in the trigger metadata.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n\n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    queueLengthStrategy: all|visibleonly\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      # Optional\n      queueLengthStrategy: \"all\" # or visibleonly. Default: all\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/beanstalkd.md",
    "content": "+++\ntitle = \"Beanstalkd\"\navailability = \"v2.16+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on beanstalkd queues\"\ngo_file = \"beanstalkd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue.\n\n```yaml\ntriggers:\n  - type: beanstalkd\n    metadata:\n      server: beanstalkd.internal-namespace:11300\n      includeDelayed: \"false\"\n      tube: \"default\"\n      activationValue: \"10\"\n      value: \"15\"\n      timeout: \"30\"\n```\n\n**Parameter list:**\n\n- `server` - Address of beanstalkd server `<host>:<port>`. If no port is specified then the scaler will default to `11300`.\n- `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted.\n- `tube` - Name of the tube to scale on.\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set.\n- `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional)\n\n### Authentication Parameters\n\nNo authentication should be needed to connect to the beanstalkd server.\n\n### Example\n\n#### Default tube with activation value\n\nHere the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'default'\n        activationValue: \"10\"\n        value: \"20\"\n```\n\n#### User-created tube with minimum replicas\n\nA minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'scaling-tube'\n        value: \"5\"\n        includeDelayed: \"true\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n- `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional).\n- `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional)\n- `key` - Key path for client authentication. Mandatory if tls enabled. (Optional)\n\n### Example with no TLS auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n\n### Example with TLS auth\n\nSince we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. \n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/cassandra\n            name: temp-cassandra-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-cassandra-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/cassandra\n  name: temp-cassandra-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-cassandra-vol\n  emptyDir:\n    medium: Memory\n```\n\nOnce we have the writable mount path set up for the certificates and keys.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n  tls: enable\n  cert: <cert content | base64encoded>\n  key: <key content | base64encoded>\n  ## Optional parameter ca ##\n  ca: <ca cert content | base64encoded>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n  - parameter: tls\n    name: cassandra-secrets\n    key: tls\n  - parameter: cert\n    name: cassandra-secrets\n    key: cert\n  - parameter: key\n    name: cassandra-secrets\n    key: key\n  ## Optional parameter ca ##\n  - parameter: ca\n    name: cassandra-secrets\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be the same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale your deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do it the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.18/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\nThere are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately.\n\n## Using the Datadog Cluster Agent (Experimental)\n\nWith this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches.\n\n### Deploy the Datadog Cluster Agent with enabled external metrics\n\nFirst, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA).\n\nIf you are using Helm to deploy the Cluster Agent, set:\n\n* `clusterAgent.metricsProvider.enabled` to `true`\n* `clusterAgent.metricsProvider.registerAPIService` to `false`\n* `clusterAgent.metricsProvider.useDatadogMetrics` to `true`\n* `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]`\n\nIf you are using the Datadog Operator, add the following options to your `DatadogAgent` object:\n\n```\napiVersion: datadoghq.com/v2alpha1\nkind: DatadogAgent\nmetadata:\n  name: datadog\nspec:\n  features:\n    externalMetricsServer:\n      enabled: true\n      useDatadogMetrics: true\n      registerAPIService: false\n  override:\n    clusterAgent:\n      env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]\n[...]\n```\n\nNOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later.\n\n### Create a DatadogMetric object for each scaling query\n\nTo use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: \"true\"` annotation, to ensure the Cluster Agent retrieves the query value. Example:\n\n```yaml\napiVersion: datadoghq.com/v1alpha1\nkind: DatadogMetric\nmetadata:\n  annotations:\n    external-metrics.datadoghq.com/always-active: \"true\"\n  name: nginx-hits\nspec:\n  query: sum:nginx.net.request_per_s{kube_deployment:nginx}\n```\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"true\"\n    datadogMetricName: \"nginx-hits\"\n    datadogMetricNamespace: \"default\"\n    targetValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    metricUnavailableValue: \"1.5\"\n    timeout: \"10s\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional)\n- `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events.\n- `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events.\n- `targetValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n- `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nThe Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below:\n\n**Common to all authentication types**\n- `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional)\n- `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed.\n- `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern.\n- `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional)\n\n**Bearer authentication:**\n- `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: datadog-config\n  namespace: my-project\ndata:\n  datadogNamespace:  # Required: namespace where the Datadog Cluster Agent is deployed\n  datadogMetricsService: # Required: Cluster Agent metrics server service name\n  unsafeSsl: # Optional: set to \"true\" to skip SSL certificate validation\n  authMode:  # Required: authentication mode (bearer)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: datadog-cluster-agent-creds\n  namespace: my-project\nspec:\n   boundServiceAccountToken:\n     - parameter: token\n       serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io\n  configMapTargetRef:\n    - parameter: datadogNamespace\n      name: datadog-config\n      key: datadogNamespace\n    - parameter: unsafeSsl\n      name: datadog-config\n      key: unsafeSsl\n    - parameter: authMode\n      name: datadog-config\n      key: authMode\n    - parameter: datadogMetricsService\n      name: datadog-config\n      key: datadogMetricsService\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx\n  maxReplicaCount: 3\n  minReplicaCount: 1\n  pollingInterval: 60\n  triggers:\n  - type: datadog\n    metadata:\n      useClusterAgentProxy: \"true\"\n      datadogMetricName: \"nginx-hits\"\n      datadogMetricNamespace: \"default\"\n      targetValue: \"2\"\n      type: \"global\"\n      timeout: \"10s\"\n    authenticationRef:\n      name: datadog-cluster-agent-creds\n```\n\n## Using the Datadog REST API\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"false\"\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n    timeout: \"10s\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false)\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n- `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n      # Optional: the HTTP timeout for this trigger\n      timeout: \"10s\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n### Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../reference/scaledobject-spec/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n### Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n#### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n#### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n### Cases of unexpected metrics value in DataDog API response\n\n#### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n#### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.18/scalers/dynatrace.md",
    "content": "+++\ntitle = \"Dynatrace\"\navailability = \"2.15+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Dynatrace metric data points\"\ngo_file = \"dynatrace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points.\n\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      host: https://dummy-instance.live.dynatrace.com/\n      metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n      # Optional\n      from: now-2d\n      threshold: \"10\"\n      # Optional\n      activationThreshold: \"5\"\n```\n\n**Parameter list:**\n\n- `host` - The Dynatrace instance to query against\n- `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)).\n\n  Some relevant aspects:\n    - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered\n    - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered\n    - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector\n- `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication the `host` and `token` parameters.\n\n**Authentication:**\n\n- `host` - The Dynatrace instance to query against\n- `token` - The API key that will be leveraged to connect to Dynatrace and make requests ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). Requires the `metrics.read` scope\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/\n  token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n        from: 'now-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html).\n\nThe trigger always requires the following information, but requires either only searchTemplateName **or** only query:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      query: \"my-query\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `query` - The query to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Examples\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        query: |\n          {\n            \"size\": 0,\n            \"query\": {\n              \"bool\": {\n                \"must\": [\n                  {\n                    \"term\": {\n                      \"service.name\": \"my-application\" }\n                  },\n                  {\n                    \"term\": {\n                      \"service.environment\": \"production\" }\n                  },\n                  {\n                    \"range\": {\n                      \"@timestamp\": {\n                        \"gte\": \"now-2m\",\n                        \"lte\": \"now-1m\"\n                      }\n                    }\n                  }\n                ]\n              }\n            },\n            \"aggs\": {\n              \"transaction_count\": {\n                \"cardinality\": {\n                  \"field\": \"transaction.id\" }\n              }\n            }\n          }\n        valueLocation: \"aggregations.transaction_count.value\"\n        targetValue: \"1000\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n        usernameFromEnv: <admin-user>  # Optional\n        passwordFromEnv: <admin-password> # Optional\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Password based authentication:**\n\n- `username` - Username for authentication. (Optional)\n- `password` - Password for authentication. (Optional)\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on Password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  etcd-username: <your username>\n  etcd-password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-etcd-secrets\n      key: etcd-username\n    - parameter: password\n      name: keda-etcd-secrets\n      key: etcd-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    enableTLS: false\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/forgejo.md",
    "content": "+++\ntitle = \"Forgejo\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on pending jobs on Forgejo repository.\"\ngo_file = \"forgejo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `forgejo-runner` trigger for Forgejo Actions. It scales based on the amount of jobs pending in given runner labels.\n\n```yaml\ntriggers:\n  - type: forgejo-runner\n    metadata:\n      # Required: the name of the registered runner \n      name: \"forgejo-runner-ubuntu\"\n      # Required: the url of the forgejo instance \n      address: \"http://localhost:3000\"\n      # Optional: Scope of the jobs to check, global is the default one and will get all the jobs in the instance with the defined labels\n      global: \"true\" \n      # Optional: User to set as a scope, global should be false, if no repo is set will get all the pending jobs for the user\n      owner: \"cobak\"\n      # Optional: Repository level scope\n      repo: \"my-repo\"\n      # Required: Will get the jobs with match with this labels\n      labels: \"ubuntu-latest\"\n```\n\n**Parameter list:**\n\n- `name` - Name of the registered runner.\n- `address` - Url of the forgejo instance.\n- `global` - Scope of the jobs to check. (Values: `true`, `false`, Default: `true`, Optional, Mutually exclusive with `owner` and `repo`)\n- `owner` - User to set as a scope. (Optional, Mutually exclusive with `global` and `repo`)\n- `repo` - User to set as a scope. (Optional, Mutually exclusive with `global` and `owner`)\n- `labels` - Labels to match the job with.\n\n\n### Authentication Parameters\n\n- `token` - Required token to connect to forgejo instance.\n\n### Options on how to set the scope (global, user, repo)\n\n1. If you set owner and repo KEDA forgejo scaler will retrieve jobs from that repository:\n   ```\n   owner: \"username\"\n   repo: \"my_repo\"\n   ```\n2. If you set the organization will retrieve the organization jobs:\n   ```\n   org: \"my_org\"\n   ```\n3. If you set global: true will retrieve all the jobs from the instance\n   ```\n   global: \"true\"\n   ```\n4. And if you don't set any of this optional fields will retrieve the jobs from the user who creates the token \n\n## Configuration \n\n### Registering runners and binding config with autoscalers\n\nTo match job endpoints with job execution, we need to pre-register a runner, save the generated JSON file as a ConfigMap, and share it with the autoscaler. review the different ways to register a runner [here](https://forgejo.org/docs/latest/admin/runner-installation/#standard-registration), select the desired scope (user, repository or global) and create the corresponding JSON file. \n\nAutoscaler definition and runner registration should match to work as expected.\n\nCreate a .runner file and a registration file with this commands, and set the output in a configmap.\n\n```shell\ndocker run -v /var/run/docker.sock:/var/run/docker.sock  -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner register --no-interactive --token xxxx --name runner --instance http://localhost:3000/ --labels ubuntu-20:docker://node:20-bookworm,docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\ndocker run -v /var/run/docker.sock:/var/run/docker.sock  -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner generate-config > registration.yaml \n```\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: runner-config\n  namespace: runners\ndata:\n  .runner: |\n    {\n        \"WARNING\": \"This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.\",\n        \"id\": 3,\n        \"uuid\": \"be6b5260-e73f-4e21-af84-8e205dbaaacd\",\n        \"name\": \"runner\",\n        \"token\": \"<global-runner-token>\",\n        \"address\": \"http://localhost:3000/\",\n        \"labels\": [\n            \"ubuntu-20:docker://node:20-bookworm\",\n            \"docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\"\n        ]\n      }\n\n---\n\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: runner-registration\n  namespace: runners\ndata:\n  registration.yaml: |\n    log:\n      # The level of logging, can be trace, debug, info, warn, error, fatal\n      level: info\n      # The level of logging for jobs, can be trace, debug, info, earn, error, fatal\n      job_level: info\n\n    runner:\n      # Where to store the registration result.\n      file: /data/.runner\n      # Execute how many tasks concurrently at the same time.\n      capacity: 1\n      # Extra environment variables to run jobs.\n      envs:\n        DOCKER_HOST: tcp://localhost:2376\n        DOCKER_TLS_VERIFY: 1\n        DOCKER_CERT_PATH: /certs/client\n      # Extra environment variables to run jobs from a file.\n      # It will be ignored if it's empty or the file doesn't exist.\n      env_file: .env\n      # The timeout for a job to be finished.\n      # Please note that the Forgejo instance also has a timeout (3h by default) for the job.\n      # So the job could be stopped by the Forgejo instance if it's timeout is shorter than this.\n      timeout: 3h\n      # The timeout for the runner to wait for running jobs to finish when\n      # shutting down because a TERM or INT signal has been received.  Any\n      # running jobs that haven't finished after this timeout will be\n      # cancelled.\n      # If unset or zero the jobs will be cancelled immediately.\n      shutdown_timeout: 3h\n      # Whether skip verifying the TLS certificate of the instance.\n      insecure: false\n      # The timeout for fetching the job from the Forgejo instance.\n      fetch_timeout: 5s\n      # The interval for fetching the job from the Forgejo instance.\n      fetch_interval: 2s\n      # The interval for reporting the job status and logs to the Forgejo instance.\n      report_interval: 1s\n      # The labels of a runner are used to determine which jobs the runner can run, and how to run them.\n      # Like: [\"macos-arm64:host\", \"ubuntu-latest:docker://node:20-bookworm\", \"ubuntu-22.04:docker://node:20-bookworm\"]\n      # If it's empty when registering, it will ask for inputting labels.\n      # If it's empty when executing the `daemon`, it will use labels in the `.runner` file.\n      labels:\n        - ubuntu-20:docker://node:20-bookworm\n        - docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\n\n    cache:\n      # Enable cache server to use actions/cache.\n      enabled: true\n      # The directory to store the cache data.\n      # If it's empty, the cache data will be stored in $HOME/.cache/actcache.\n      dir: \"\"\n      # The host of the cache server.\n      # It's not for the address to listen, but the address to connect from job containers.\n      # So 0.0.0.0 is a bad choice, leave it empty to detect automatically.\n      host: \"\"\n      # The port of the cache server.\n      # 0 means to use a random available port.\n      port: 0\n      # The port of the cache proxy.\n      # 0 means to use a random available port.\n      proxy_port: 0\n      # The external cache server URL. Valid only when enable is true.\n      # If it's specified, it will be used to set the ACTIONS_CACHE_URL environment variable. The URL should generally end with \"/\".\n      # Otherwise it will be set to the the URL of the internal cache server.\n      external_server: \"\"\n      # The shared cache secret. When communicating with a cache server, the runner uses this secret to verify the authenticity of the cache requests.\n      # When using an external cache server it is required to set the same secret for the runner and the cache server.\n      secret: \"\"\n      # Overrides the ACTIONS_CACHE_URL passed to workflow containers. This should only be used if the runner host is not reachable from the\n      # workflow containers, and requires further setup.\n      actions_cache_url_override: \"\"\n\n    container:\n      # Specifies the network to which the container will connect.\n      # Could be host, bridge or the name of a custom network.\n      # If it's empty, create a network automatically.\n      network: host\n      # Whether to create networks with IPv6 enabled. Requires the Docker daemon to be set up accordingly.\n      # Only takes effect if \"network\" is set to \"\".\n      enable_ipv6: false\n      # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker).\n      privileged: false\n      # And other options to be used when the container is started (eg, --add-host=my.forgejo.url:host-gateway).\n      options: -v /certs/client:/certs/client\n      # The parent directory of a job's working directory.\n      # If it's empty, /workspace will be used.\n      workdir_parent:\n      # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob\n      # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted.\n      # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to:\n      # valid_volumes:\n      #   - data\n      #   - /src/*.json\n      # If you want to allow any volume, please use the following configuration:\n      # valid_volumes:\n      #   - '**'\n      valid_volumes:\n        - /certs/client\n      # overrides the docker client host with the specified one.\n      # If \"-\" or \"\", an available docker host will automatically be found.\n      # If \"automount\", an available docker host will automatically be found and mounted in the job container (e.g. /var/run/docker.sock).\n      # Otherwise the specified docker host will be used and an error will be returned if it doesn't work.\n      docker_host: \"-\"\n      # Pull docker image(s) even if already present\n      force_pull: false\n      # Rebuild local docker image(s) even if already present\n      force_rebuild: false\n\n    host:\n      # The parent directory of a job's working directory.\n      # If it's empty, $HOME/.cache/act/ will be used.\n      workdir_parent:\n\n```\n\n### Create a token on forgejo\n\nThe autoscaler will continuously fetch new waiting jobs from Forgejo, so it requires a properly configured token with the appropriate permissions. Navigate to **Forgejo > User settings > Applications > Access Tokens** and generate a new token. This token will be used by the autoscaler\n\n### Configuring KEDA Autoscaler\n\nCreate a new custom resource with the required parameters and custom fields based on the scope chosen during runner registration. For example, set `global=\"true\"` for global runners or specify `repo=xxx` and `owner=xxx` for repository level runners.\n\nChoose the runner image you want to use (>6.1 of forgejo runner releases) or a custom one with `--one-job` command. \n\nApply the new custom resource to your cluster.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: forgejo-runner-secret\n  namespace: runners\ndata:\n  token: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: forgejo-runner-creds\n  namespace: runners\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: forgejo-runner-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  labels:\n    app: forgejo-runner\n  name: upload-platform-forgejo-runner\n  namespace: runners\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: forgejo-runner\n      spec:\n        volumes:\n          - name: runner-data\n            emptyDir: {}\n          - name: runner-config\n            configMap:\n              name: upload-platform-runner-config\n          - name: runner-registration\n            configMap:\n              name: upload-platform-runner-registration\n          - name: docker-certs\n            emptyDir: {}\n        restartPolicy: Never\n        shareProcessNamespace: true\n        containers:\n          - name: runner\n            image: code.forgejo.org/forgejo/runner:6.3.1\n            command:\n              - sh\n              - -c\n              - |\n                while ! nc -z localhost 2376 </dev/null; do \n                  echo 'waiting for docker daemon...'\n                  sleep 5\n                done\n\n                cp /config/.runner /data/.runner\n\n                exec forgejo-runner -c /registration/registration.yaml one-job\n            securityContext:\n              privileged: true\n              runAsUser: 0\n            env:\n              - name: DOCKER_HOST\n                value: tcp://localhost:2376\n              - name: DOCKER_CERT_PATH\n                value: /certs/client\n              - name: DOCKER_TLS_VERIFY\n                value: \"1\"\n            volumeMounts:\n              - name: docker-certs\n                mountPath: /certs\n              - name: runner-data\n                mountPath: /data\n              - name: runner-registration\n                mountPath: /registration\n                readOnly: false\n              - name: runner-config\n                mountPath: /config\n                readOnly: false\n          - name: daemon\n            image: docker:27.4.1-dind\n            command:\n              - sh\n              - -c\n              - |\n                dockerd-entrypoint.sh 2>&1 &\n\n                while kill -0 7 2>/dev/null\n                  do sleep 10 \n                  echo \"watching main job execution\"\n                done;\n\n                sleep 10\n\n                echo \"main container exited, stopping dind\"\n                exit 0\n            env:\n              - name: DOCKER_TLS_CERTDIR\n                value: /certs\n              - name: DOCKER_HOST\n                value: tcp://0.0.0.0:2376\n            securityContext:\n              privileged: true\n              runAsUser: 0\n            volumeMounts:\n              - name: docker-certs\n                mountPath: /certs\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n    - type: forgejo-runner\n      metadata:\n        name: \"runner\"\n        address: \"http://localhost:3000/\"\n        global: \"true\"\n        labels: \"ubuntu-20,docker\"\n      authenticationRef:\n        name: forgejo-runner-creds\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    filterDuration: '1' # Optional - Default is 2\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # The 'subscriptionSize' setting is DEPRECATED and will be removed in v2.20 - Use 'mode' and 'value' instead\" \n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    valueIfNull: '0.0' # Optional - Default is \"\"\n    activationValue: \"10.5\" # Optional - Default is 0\n    timeHorizon: \"1m\" # Optional - Default is 2m and with aggregation 5m\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`)\n\n- `valueIfNull` - Value returned if request returns no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    filterDuration: '1' # Optional - Default is 2\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\", defaults to \"false\" (scale on default runner labels)\n      noDefaultLabels: \"{noDefaultLabels}\"\n      # Optional: When enabled unlabeled jobs will not match unlabeled runners. Can be either \"true\" or \"false\", defaults to \"false\"\n      matchUnlabeledJobsWithUnlabeledRunners: \"{matchUnlabeledJobsWithUnlabeledRunners}\"\n      # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either \"true\" or \"false\", defaults to \"false\"\n      enableEtags: \"{enableEtags}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabels` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"). (Values: `true`,`false`, Default: \"false\", Optional)\n- `matchUnlabeledJobsWithUnlabeledRunners` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: \"false\", Optional)\n- `enableEtags` -  Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabelsFromEnv` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\". (Optional)\n- `matchUnlabeledJobsWithUnlabeledRunnersFromEnv` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows,\nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations:\n\n- Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories.\n- Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**Fine-Tuning**\n\nThe current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters.\n\nFor example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly.\n\n*Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).*\n\nAt the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) (**The 'minMetricValue' setting is DEPRECATED and will be removed in v2.20 - Use 'activationTargetMetricValue' instead**)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueName: <queue-name> # REQUIRED - Your queue name\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n    unsafeSsl: \"false\" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ).\n- `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\nExample with Basic Auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n        usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n\nExample with Basic Auth and TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n  cert: <your tls.crt>\n  key: <your tls.key>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n    - parameter: cert\n      name: keda-ibmmq-secret\n      key: cert\n    - parameter: key\n      name: keda-ibmmq-secret\n      key: key\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org # Required for InfluxDB v2.x, optional for InfluxDB v3.x\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      metricKey: 'mymetric' # Required for Influx v3. Ignored for v2. See details in \"Parameter List\" section\n      queryType: 'InfluxQL' # Required for Influx v3. Ignored for v2. See details in \"Parameter List\" section\n      influxVersion: '2' # Optional: Defaults to 2.\n      database: 'some-influx-db' # Required for Influx v3\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc (Optional, Required if `influxVersion: '2'`).\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `influxVersion` - Specifies the version of InfluxDB being used. (Values: `2`, `3`, Default: `2`, Optional)\n- `database` - The name of the InfluxDB database to query. Required for InfluxDB v3.x. (Optional for InfluxDB v2.x)\n- `metricKey` - The name of the metric to be used for scaling decisions. This is required for InfluxDB v3.x and ignored for InfluxDB v2.x. It is used to identify the metric in the query results. For a `query` of `SELECT mean(\"mymetric\") AS \"metric_name\" FROM...` use `metricKey: 'metric_name'`. (Optional, Required if `influxVersion: '3'`)\n- `queryType` - Specifies the type of query being used. For InfluxDB v3.x, this can be either `InfluxQL` or `FlightSQL`. For InfluxDB v2.x, this parameter is ignored. (Values: `InfluxQL`, `FlightSQL`, Default: `InfluxQL`, Optional)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example (InfluxDB v2)\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` (v2) scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n\n### Example (InfluxDB v3)\n\nBelow is a similar example for Influx v3 using an `InfluxQL` query.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        database: 'my-metrics-db'\n        influxVersion: '3'\n        queryType: 'InfluxQL'\n        metricKey: 'mean'\n        thresholdValue: '2'\n        activationThresholdValue: '10'\n        query: |\n          SELECT mean(\"water_level\") FROM \"h2o_feet\"\n          GROUP BY time(5m)\n          ORDER BY time DESC LIMIT 1;\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    format: \"json\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur. This value can be a float.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n> **Notice:**\n> The Stan scaler (NATS Streaming) is DEPRECATED and will be removed in v2.19 - Use scaler [nats-jetstream](./nats-jetstream.md) instead.\n> See also the deprecation notice [here](https://nats-io.gitbook.io/legacy-nats-docs/nats-streaming-server-aka-stan).\n\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n**TLS Authentication**\n\n- `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### Example without any TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with no TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n\n#### Example with TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-stan-secrets\n  namespace: default\ndata:\n  tls: enable\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-stan-secrets\n      key: tls\n    - parameter: ca\n      name: keda-stan-secrets\n      key: ca\n    - parameter: cert\n      name: keda-stan-secrets\n      key: cert\n    - parameter: key\n      name: keda-stan-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"true\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\nAutoscaling trigger based on transaction duration average metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n\nAutoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO\"\n        noDataError: \"true\"\n        threshold: '300'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/nsq.md",
    "content": "+++\ntitle = \"NSQ\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NSQ topic/channel depth.\"\ngo_file = \"nsq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. \n\n```yaml\ntriggers:\n- type: nsq\n  metadata:\n    nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n    topic: \"example_topic\"\n    channel: \"example_channel\"\n    depthThreshold: \"10\"\n    activationDepthThreshold: \"0\"\n    useHttps: \"false\"\n    unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `<hostname>:<port>`.\n- `topic` - Name of the NSQ datastream that the `channel` relates to.\n- `channel` - Name of the channel used to calculate depth.\n- `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional)\n- `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional)\n- `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n> **Notice:**\n> - Since [\"channels are created on first use by subscribing to the named channel\"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0.\n> - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nsq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nsq-consumer-deployment\n  triggers:\n  - type: nsq\n    metadata:\n      nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n      topic: \"example_topic\"\n      channel: \"example_channel\"\n      depthThreshold: \"10\"\n      activationDepthThreshold: \"0\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.18/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for three connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret).\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nIt is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity.  \nMore details and an example are provided down below.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n\n**Azure Access Token authentication:**\n\n#### Prerequisites:\n- The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity).\n- The UAMI should be granted access to the table mentioned in the query performed by KEDA.  \nThis can be achieved by:\n  - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role.\n  - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like  \n  `GRANT ALL ON <TABLE_REF> TO \"<AZURE_UAMI_NAME>\";`.\n\nNext, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process.\n  - `host` - FQDN of the Azure Postgres Flexible Server.\n  - `userName` - Name of the UAMI Azure identity (`<AZURE_UAMI_NAME>`).\n  - `port` - Postgresql port (the default value is `\"5432\"`, please have a look at the `Remarks` down below).\n  - `dbName` - Postgresql Database name.\n  - `sslmode` - SSL policy for communicating with database (the value should be `require`).\n\n\n#### Remarks\n\n- While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port.\n\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-pg-flex-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      authenticationRef:\n        name: azure-pg-flex-auth\n      metadata:\n        host: <AZURE_POSTGRES_FLEX_SERVER_FQDN>\n        port: \"5432\"\n        userName: <UAMI_NAME>\n        dbName: <DB_NAME>\n        sslmode: require\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```"
  },
  {
    "path": "content/docs/2.18/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n    timeout: \"1000\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.18/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://<host>:<port>/<vhost> # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either `amqp`, `http`, or `auto` for auto-detection based on the `host` value. Default value is `auto`.\n    mode: QueueLength # Supported modes are `QueueLength`, `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` or `ExpectedQueueConsumptionTime`\n    value: \"100.50\" # A value defining the threshold (per instance) that, when exceeded, triggers the scaling.\n    activationValue: \"10.5\" # Optional. Activation threshold, which by default is 0.\n    queueName: testqueue # Name of the queue.\n    vhostName: / # Optional. If not specified, use the VHost in the `host` connection string. Required for Azure AD Workload Identity authorization (see below).\n    # You can use existing environment variables to read configuration from. For details see \"Parameters list\" section.\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter.\n    usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of `TriggerAuthentication`.\n    passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of `TriggerAuthentication`.\n    unsafeSsl: true # Optional. Whether to allow unsafe SSL connections.\n    timeout: 1000 # Optional. Custom timeout for the HTTP client used in this scaler.\n```\n\n**Parameters list:**\n\n- `host` - RabbitMQ host address in the format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example, the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain `vhost`, then the trailing slash is required, e.g. `http://guest:password@localhost:5672/`. When using a username with password consider using `hostFromEnv` or a `TriggerAuthentication`.\n- `queueName` - Name of the queue to read required information and stats from.\n- `mode` - Trigger mode. See [Choosing the right trigger mode](#choosing-the-right-trigger-mode) for additional details. Can be one of:\n  - `QueueLength` - trigger on number of messages in the queue\n  - `MessageRate` - trigger on the publishing rate reported by the queue\n  - `DeliverGetRate` - trigger on the rate of delivered messages (to consumers or in response to `basic.get`, both acknowledged and not) reported by the queue\n  - `PublishedToDeliveredRatio` - trigger on the value of ratio of `MessageRate` to `DeliverGetRate`\n  - `ExpectedQueueConsumptionTime` - trigger on the value of expected time (in seconds) of consumption of all messages currently available in the queue (utilizes `QueueLength`, `MessageRate` and `DeliverGetRate` metrics).\n- `value` - A value defining the threshold (per instance) that, when exceeded, triggers the scaling (can be a floating-point number depending on the trigger mode).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) (default: `0`; optional; can be a floating-point number).\n- `protocol` - Protocol to be used for communication (values: `auto`, `http`, `amqp`; default: `auto`; optional).\n- `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (it's optional by default but **it is required** if Azure AD Workload Identity authorization is used).\n- `queueLength` - **DEPRECATED: please use `mode: QueueLength` and `value: ##` instead**. Defines a threshold value for the queue length passed to the scaler. For example: if one pod can handle 10 messages, set the queue length target to `10`. If the actual number of messages in the queue is 30, the scaler will scale up to 3 pods. Default is set to `20` unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of using full name (values: `true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol).\n- `pageSize` - This parameter allows setting the page size (default: `100`; optional; only applies when `useRegex` is set to `true`).\n- `operation` - Operation that will be applied to compute the number of messages in case when `useRegex` is enabled (values: `sum`, `max`, `avg`; defaults: `sum`; optional).\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT` (optional; only applies to hosts that use the `http` protocol).\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (ready messages only; values:`true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol).\n- `unsafeSsl` - Whether to allow unsafe SSL connections (values: `true`, `false`, default: `false`).\n\nSome parameters can be provided using environment variables instead of setting them directly in metadata:\n- `hostFromEnv` - reads the host and port of the RabbitMQ server from selected environment variable (in similar format as `host` parameter)\n- `usernameFromEnv` - reads the username from selected environment variable, which is used to connect to the broker’s management endpoint\n- `passwordFromEnv` - reads the password from selected environment variable, which is used to connect to the broker’s management endpoint.\n\n> 💡 **Notes:** \n> - `host`/`hostFromEnv` has an optional VHost name after the host slash which will be used to scope API request\n> - when using `host`/`hostFromEnv` or `TriggerAuthentication`, the supplied password cannot contain special characters\n> - trigger modes `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` require `http` protocol.\n> - setting `useRegex` to `true` also requires `protocol` to be set to `http`.\n\n> ⚠ **Important:**\n> - If you have unacknowledged messages and you want to have these counted for the scaling to happen, make sure to utilize the `http` protocol (only REST API interface allows for these to be counted).\n> - If scaling against many is desired, then the `ScaledObject` should have all desired triggers defined. HPA will scale based on the largest result considering each of triggers independently.\n\n### Choosing the right trigger mode\n\nBelow you can find available trigger modes with most common usage scenarios:\n- `QueueLength` - Mainly used to scale messages consuming services, where it is desired to keep number of messages in the queue at selected, nominal level.\n- `MessageRate` - Mainly used to scale messages consuming services, where it is desired to keep the consumption rate up to messages publication rate (or higher).\n- `DeliverGetRate` - This specific trigger is actually a byproduct of the resulting implementation of `PublishedToDeliveredRatio` trigger (it was implemented to be used within `scalingModifiers` as a part of composite metric), yet it still has its use in some scenarios. E.g. assuming there's a well known consumer service performance ballpark, `DeliverGetRate` trigger can be utilized to scale out messages publishing service in order to increase publication rate. In this particular example however, upper publication rate limit must be properly guarded by another trigger or by [`maxReplicaCount`](./../reference/scaledobject-spec/#maxreplicacount) so as not to scale infinitely (which could result in overloading the broker, or consumers, or both).\n- `PublishedToDeliveredRatio` - This trigger is used mainly to control consumer pods scaling to keep publishing and consuming rates at stable level. Assuming that this is the case, the principle of operation is this:\n  - if publishing rate is greater than `value` (usually it is a value slightly above `1`), trigger will initiate scale-out process to launch more consumer pods\n  - if publishing rate is equal to consumption rate (value `1`) then it is the indicator that capacity of consumers is sufficient for handling ongoing messages processing and no additional pods need to be added to the pool\n  - if ratio is below `1`, HPA can gracefully take down some consumers but keep messages processing rate at stable level.\n- `ExpectedQueueConsumptionTime` - A trigger primarily used to scale consumer pods, which uses estimate value of pending time to deliver all available messages in the queue to the consumers. If it becomes active in this particular scenario, returned metric indicates growing number of messages due either increased publishing rate or degraded performance of currently active number of consumers. It relies on proper setting of `pollingInterval` (see below for details).\n\n> ⚠ **Important:**\n> - With `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` it is advised to set `metricType: Value` in the trigger configuration to rely on absolute metric value and not the average value across all scaled pods. For reference see [`triggers.metricType`](./../reference/scaledobject-spec/#triggers) and [`scalingModifiers.metricType`](./../reference/scaledobject-spec/#scalingmodifiersmetrictype).\n> - When using `PublishedToDeliveredRatio`, having stable publication to consumption rate may not indicate that consumers pool is of the right size to do the job, since the messages consuming capabilities can change over time, which may result in much higher number of consumers than actually needed. It is then recommended to periodically re-evaluate consumers pool size using different, probably external metric (e.g. consumers count number, size of prefetch buffer, consumer performance, etc.).\n> - Since `ExpectedQueueConsumptionTime` trigger mode is based on the expected time (in seconds) for the selected queue to be emptied of all messages (including estimated count of published messages during sample probing), it must be served with `pollingInterval` set to 1 second. However, in case where such frequent polling may be expensive, it is recommended to use `ExpectedQueueConsumptionTime` in `scalingModifiers` using additional triggers values in formula like so: `(ExpectedQueueConsumptionTime - (QueueLength / DeliverGetRate)) * pollingInterval + (QueueLength / DeliverGetRate)`.\n\n### Authentication Parameters\n\n`TriggerAuthentication` CRD is used to connect and authenticate to RabbitMQ:\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n  > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n- `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (optional, but **required** if Azure AD Workload Identity authorization is used).\n\n#### Username and Password based authentication\n\nThis allows sensitive credentials to be stored and managed separately from the connection string:\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** If username or password are set in `TriggerAuthentication` or environment variables, they will override any credentials provided in the `host` parameter.\n\n#### TLS authentication\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ will not be used. Valid values are `enable` or `disable` (optional; the default is `disable`).\n- `ca` - Certificate authority file for TLS client authentication (optional).\n- `cert` - Certificate for client authentication (optional).\n- `key` - Certificate Key for client authentication (optional).\n\n> 💡 **Note:** Using RabbitMQ host with AMQPS protocol will require enabling the TLS settings and passing the required parameters.\n\n#### Azure Workload Identity authentication\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use `TriggerAuthentication` CRD with `podIdentity.provider = azure-workload` and with `workloadIdentityResource` parameter, which will hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Currently, only HTTP protocol is supported for AKS Workload Identity.\n\n### Configuration examples\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672\n  vhostName: vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: vhostName\n      name: keda-rabbitmq-secret\n      key: vhostName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQP protocol with username and password authorization:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://localhost:5672/vhost (no username/password)\n  username: <username> # base64 encoded value of username\n  password: <password> # base64 encoded value of password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: username\n      name: keda-rabbitmq-secret\n      key: username\n    - parameter: password\n      name: keda-rabbitmq-secret\n      key: password \n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS authorization:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `MessageRate` and `QueueLength` triggers):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger) and enabled `useRegex`:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `DeliverGetRate` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: DeliverGetRate\n      value: \"30\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n\n#### HTTP protocol (with `PublishedToDeliveredRatio` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: PublishedToDeliveredRatio\n      value: \"1.1\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n\n#### HTTP protocol (with `PublishedToDeliveredRatio` trigger used together with `scalingModifiers`)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    name: p2d_ratio\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: PublishedToDeliveredRatio\n      value: \"1\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n  - type: rabbitmq\n    name: qlen\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"100\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n  advanced:\n    # Bind QueueLength and PublishedToDeliveredRatio together to control trigger value\n    scalingModifiers:\n      metricType: Value\n      # Trigger if either one of conditions is met:\n      # - publishing to delivery rate exceeds factor of 1.2\n      # - queue length contains more than 1.2K messages\n      formula: \"max(p2d_ratio, qlen/1000)\"\n      target: 1.2\n```\n\n#### HTTP protocol (with `ExpectedQueueConsumptionTime` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  pollingInterval: 1\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    name: eqct\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: ExpectedQueueConsumptionTime\n      value: \"20\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"myprimary\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.18/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars, SeleniumHQ\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration with default values represent.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: ''  # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`).\n      browserVersion: '' # Optional.\n      platformName: '' # Optional.\n      unsafeSsl: false # Optional.\n      activationThreshold: 0 # Optional.\n      nodeMaxSessions: 1 # Optional.\n      enableManagedDownloads: true # Optional.\n      capabilities: '' # Optional.\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional).\n- `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional).\n- `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional)\n\n**Trigger Authentication**\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional)\n- `accessToken` - Access token. This is required when `authType` is set a value. (Optional)\n\n### Example\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion`\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nNoted:\n- From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details.\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nWith above script, the request is sent to Grid. Via GraphQL response, it looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 0,\n      \"totalSlots\": 0\n    },\n    \"nodesInfo\": {\n      \"nodes\": []\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nIn Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata.\n\nWhen the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 1,\n      \"totalSlots\": 1\n    },\n    \"nodesInfo\": {\n      \"nodes\": [\n        {\n          \"id\": \"UUID-of-Node\",\n          \"status\": \"UP\",\n          \"sessionCount\": 0,\n          \"maxSession\": 1,\n          \"slotCount\": 1,\n          \"stereotypes\": \"[{\\\"slots\\\": 1, \\\"stereotype\\\": {\\\"browserName\\\": \\\"chrome\\\", \\\"browserVersion\\\": \\\"\\\", \\\"platformName\\\": \\\"Linux\\\"}}]\",\n          \"sessions\": []\n        }\n      ]\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nNow, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in.\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName`\n\nMoreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome-131\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:131.0\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: '131.0'\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-131\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-131\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '131.0'\n        unsafeSsl: 'true'\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '131.0')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n#### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads`\n\nIn image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node\n          - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS\n            value: \"true\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Scaler trigger param configuration should be aligned with Node stereotype.\n        enableManagedDownloads: \"true\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid\noptions.enable_downloads = True\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata with extra `capabilities`\n\nFor an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options\n          - name: SE_NODE_STEREOTYPE_EXTRA\n            value: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536\n        capabilities: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes\noptions.set_capability('myApp:version', 'beta')\noptions.set_capability('myApp:publish', 'public')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Firefox browser\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-firefox\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-firefox\n          image: selenium/node-firefox:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-firefox\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-firefox\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = FirefoxOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Edge browser\n\nSimilarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-edge\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-edge\n          image: selenium/node-edge:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-edge\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-edge\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = EdgeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions`\n\nIn case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n        - name: SE_NODE_OVERRIDE_MAX_SESSIONS\n          value: 'true'\n        - name: SE_NODE_MAX_SESSIONS\n          value: '4'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        nodeMaxSessions: 4\n        unsafeSsl: 'true'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n  graphql-username: base64 encoded value of GraphQL Username\n  graphql-password: base64 encoded value of GraphQL Password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n  - parameter: username\n    name: selenium-grid-secret\n    key: graphql-username\n  - parameter: password\n    name: selenium-grid-secret\n    key: graphql-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/solace-pub-sub-dm.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker - Direct Messaging\"\navailability = \"2.18+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker - Direct Messaging\"\ngo_file = \"solace_dm_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-direct-messaging` trigger that scales based on a Solace PubSub+ Event Broker direct messaging rates for all the clients in a message vpn that matches a common client name prefix.\n\n> &#128161; **Note:**\nThis trigger is for **Direct messaging** only, it provides the ability to scale the number of client instances automatically based upon transient metrics for shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length), all this metrics exists as long as the clients are connected.\n\nIf you need to use **Guaranteed messaging** (Solace PubSub+ Event Broker queue) you should use the `solace-event-queue` trigger.\n\n```yaml\n  triggers:\n  - type: solace-direct-messaging\n    metricType: Value\n    metadata:\n      solaceSempBaseURL:  \"https://solace_broker1:943,https://solace_broker2:943\"\n      messageVpn: \"message-vpn\"\n      clientNamePattern: \"client-name-pattern\"\n      unsafeSSL: \"true\"\n      queuedMessagesFactor: '3'\n      aggregatedClientTxMsgRateTarget: '600'      \n      aggregatedClientTxByteRateTarget: '0'\n      aggregatedClientAverageTxByteRateTarget: '0'\n      aggregatedClientAverageTxMsgRateTarget: '0'\n      usernameFromEnv: 'ENV_VAR_USER'\n      passwordFromEnv: 'ENV_VAR_PWD'\n    authenticationRef:\n      name: trigger-authentication-ref\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Comma separated list of Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`. (Required)\n\n- `messageVpn` - Message VPN hosted on the Solace broker from which the metrics will be collected. (Required)\n\n- `clientNamePattern` - Client name pattern that will be used to identify the clients that are consuming from a shared subscription. (Required). It will be used to match all the client names that match the expression: **' \\*client-name-pattern\\* '**\n\n- `unsafeSSL` - Flag to enable unsafe host urls (self signed certificates). (Default:  `false`, Optional)\n\n- `queuedMessagesFactor` - Flag to to increase weight on queued messages (D-1) and scale faster to avoid discarding messages. (Default:  `3`, Optional)\n\n- `aggregatedClientTxMsgRateTarget` - Target number messages per second the clients in the shared subscription are expected to consume, if the actual aggregated messages per second number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientTxByteRateTarget` - Target number bytes per second the clients in the shared subscription are expected to consume, if the actual aggregated bytes per second number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientAverageTxByteRateTarget` - Target average number messages per minute the clients in the shared subscription are expected to consume, if the actual aggregated messages per minute number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientAverageTxMsgRateTarget` - Target average number bytes per minute the clients in the shared subscription are expected to consume, if the actual aggregated bytes per minute number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `usernameFromEnv` - Environment variable set with SEMP user account. (Optional)\n\n- `passwordFromEnv` - Environment variable set with password for the user account. (Optional)\n\n**Parameter Requirements:**\n\n- Parameters resolving the target host and shared subscription are all **required:** `solaceSempBaseURL`, `messageVpn`, `clientNamePattern`\n\n- **At least** one of `aggregatedClientTxMsgRateTarget`, `aggregatedClientTxByteRateTarget`, `aggregatedClientAverageTxByteRateTarget` or  `aggregatedClientAverageTxMsgRateTarget` is **required**.\n\nIf more than one target values are present, calculation is done for each metric and the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n\nFor more details please see [Horizontal Pod Autoscaling - Algorithm details](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)\n\nThe `solace-direct-messaging` Scaler polls the Solace SEMP REST API to get transient metrics from connected clients. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the  trigger to function. \n\nThese values can be set in several different ways:\n  - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n  - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\nThe objects in the example below are declared in `namespace=solace`. It is not required to \ndo so. If you do define a namespace for the configuration objects, then they should all be declared \nin the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval:  3\n  cooldownPeriod:  60\n  #Always > 0 because is direct messaging!\n  minReplicaCount:  1\n  maxReplicaCount: 20\n  advanced:\n    restoreToOriginalReplicaCount: true\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n         #The stabilization window is used to restrict the flapping of replica count when the metrics used for scaling keep fluctuating.\n         #The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale.\n         #All desired states from the past 1 minutes (60secs) will be considered\n          stabilizationWindowSeconds: 60\n          #Policy (Pods) allows at most 1 replicas to be scaled down in 10 seconds.\n          policies:\n          - type:          Pods\n            value:         1\n            #Indicates the length of time in the past for which the policy must hold true\n            periodSeconds: 10\n        scaleUp:\n          stabilizationWindowSeconds: 0\n          #Policy (Pods) allows at most 3 replicas to be scaled up in 3 seconds.\n          policies:\n          - type:          Pods\n            value:         5\n            periodSeconds: 3\n          selectPolicy:    Max\n  triggers:\n  - type: solace-direct-messaging\n    #we don’t want to take the average of the given metric across all replicas, just the value\n    metricType: Value\n    metadata:\n      solaceSempBaseURL:  \"https://broker1.messaging.solace.cloud:943,https://broker2.messaging.solace.cloud:943\"\n      messageVpn: \"consumer_vpn\"\n      #all the clients that match this client name pattern will be considered for metric gathering\n      clientNamePattern: \"direct-messaging-simple\"\n      #to be able to use self signed certs\n      unsafeSSL: \"false\"\n      #to increase weight on queued messages and scale faster\n      #if there are messages queued means we are behind\n      queuedMessagesFactor: '3'\n      #Metrics\n      aggregatedClientTxMsgRateTarget: '600'      \n      aggregatedClientTxByteRateTarget: '0'\n      aggregatedClientAverageTxByteRateTarget: '0'\n      aggregatedClientAverageTxMsgRateTarget: '0'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD      \n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n**Note:**\nThis trigger is for **Guaranteed messaging** (Solace PubSub+ Event Broker queue) only, it provides the ability to scale the number of client instances automatically based upon metrics for a Solace PubSub+ Event Broker queue.\n\nIf you need to use **Direct messaging**, shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length) you should use the `solace-direct-messaging` trigger.\n\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint comma-separated host list in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **solaceSempBaseURL** can contain either a single URL or a comma-separated list of URLs.  If multiple URLs are provided, the scaler will iterate over the list until it is both able to connect the broker successfully AND the broker's messageVpn is in the **UP** state.  All brokers in the list will share the same authentication configuration.  This feature was primarily added to support Solace's Disaster Recovery Replication feature.\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/solarwinds.md",
    "content": "+++\ntitle = \"SolarWinds\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics from SolarWinds.\"\ngo_file = \"solarwinds_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solarwinds` trigger that scales based on metrics from SolarWinds.\n\n```yaml\ntriggers:\n- type: solarwinds\n  metadata:\n    host: https://api.na-01.cloud.solarwinds.com\n    targetValue: \"1\"\n    activationValue: \"3\"\n    metricName: \"k8s.pod.cpu.usage.seconds.rate\"\n    aggregation: \"AVG\"\n    intervalS: \"60\"\n    filter: \"k8s.deployment.name:my-deployment\"\n```\n\n**Parameter list:**\n\n- `host` - The SolarWinds API endpoint. (Example: `https://api.na-01.cloud.solarwinds.com`)\n- `targetValue` - Value to reach to start scaling. (This value can be an integer or float)\n- `activationValue` - Target value for activating the scaler. (Optional, Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds))\n- `metricName` - The name of the metric to monitor.\n- `aggregation` - The aggregation method to use. (Values: `COUNT`, `MIN`, `MAX`, `AVG`, `SUM`, `LAST`)\n- `intervalS` - The interval in seconds for the metric collection.\n- `filter` - The filter to apply to the metric data. (Optional, Examples below)\n  - `key1:value1 key2:value2` - Search using key values pairs with a delimiting space for an implicit AND\n  - `key:[value1,value2]` - Search using IN operator (key equals value1 or value2)\n  - `key:~value` - Search using CONTAINS operator\n  - `key>value1 key<value2` - Use comparative operators for number based keys such as (“=”, “>”, “<“, “<=”, “>=”) (key between value1 and value2)\n  - `NOT key:\"\"` - Search using NOT operator and EMPTY value (key is not empty)\n  - `entities(attribute:value)` - search using attributes of entities related to the metric data (metric values associated with entity having attribute equals value)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing the necessary credentials.\n\n**Credential based authentication:**\n\n- `apiToken` - The API token for accessing SolarWinds Observability. See [doc](https://documentation.solarwinds.com/en/success_center/observability/content/settings/api-tokens.htm) for more information.\n\n### Example\n\nHere is an example of a SolarWinds Scaler with authentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solarwinds-secret\n  namespace: default\ndata:\n  apiToken: <base64-encoded-api-token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solarwinds-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiToken\n      name: solarwinds-secret\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solarwinds-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: nginx\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 2\n  triggers:\n  - type: solarwinds\n    authenticationRef:\n      name: solarwinds-auth\n    metadata:\n      host: https://api.na-01.cloud.solarwinds.com\n      targetValue: \"3\"\n      activationValue: \"3\"\n      metricName: \"k8s.pod.cpu.usage.seconds.rate\"\n      aggregation: \"AVG\"\n      intervalS: \"60\"\n      filter: \"k8s.deployment.name:my-deployment\"\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/splunk-observability.md",
    "content": "+++\ntitle = \"Splunk Observability\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk Observability Cloud metrics.\"\ngo_file = \"splunk_observability_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk-observability` trigger that scales based on the result of a metric series queried from the Splunk Observability Cloud platform with a [SignalFlow query](https://dev.splunk.com/observability/docs/signalflow/).\n\n\n```yaml\ntriggers:\n  - type: splunk-observability\n    metadata:\n      # Required: SignalFlow query to retrieve the desired metric time series\n      query: \"data('demo.trans.latency').max().publish()\"\n      # Required: Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds\n      duration: \"10\"\n      # Required: Threshold to reach to start scaling\n      targetValue: \"400.1\"\n      # Required: Target value for activating the scaler\n      activationTargetValue: \"1.1\"\n      # Required: Specifies how the Metrics Time Series should be processed, options are \"min\" (minimum value), \"max\" (maximum value), and \"avg\" (average value)\n      queryAggregator: \"avg\"\n```\n\n**Parameter list:**\n\n- `query` - SignalFlow query for querying the desired metrics.\n- `duration` - Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds.\n- `targetValue` - Threshold to reach to start scaling.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `queryAggregator` - When querying metrics from Splunk Observability Cloud, initially a Metric Time Series (MTS) is returned, a list consisting of several datapoints. The 'queryAggregator' specifies how this series of metrics should be \"rolled up\". Valid values for this field are \"avg\", which returns the average, \"min\", which returns the minimum of the metrics in the series, and \"max\", which returns the maximum value.\n\n**Parameter list:**\n\n- `accessToken` - Splunk Observability Cloud Access Token.\n- `realm` - Splunk Observability Cloud Realm.\n\n## Configuration Example\n\nThe following example shows how to scale a simple NGINX employment with the help of KEDA and the Splunk Observability Cloud scaler:\n\n#### Simple NGINX employment\n\n```yaml\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n        - name: nginx\n          image: nginx:1.14.2\n          ports:\n            - containerPort: 80\n```\n\n#### Authentication\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-secrets\ndata:\n  accessToken: <base64-encoded Splunk Observability Cloud Access Token>\n  realm: <base64-encoded Splunk Observability Cloud Realm>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-splunk-secret\nspec:\n  secretTargetRef:\n    - parameter: accessToken\n      name: splunk-secrets\n      key: accessToken\n    - parameter: realm\n      name: splunk-secrets\n      key: realm\n```\n\n#### KEDA Scaler\n\n```yaml\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: nginx\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n    - type: splunk-observability\n      metricType: Value\n      metadata:\n        query: \"data('demo.trans.count', filter=filter('demo_host', 'server6'), rollup='rate').sum(by=['demo_host']).publish()\"\n        duration: \"10\"\n        queryValue: \"400.1\"\n        activationQueryValue: \"1.1\"\n        queryAggregator: \"max\" # 'min', 'max', or 'avg'\n      authenticationRef:\n        name: keda-trigger-auth-splunk-secret\n```"
  },
  {
    "path": "content/docs/2.18/scalers/splunk.md",
    "content": "+++\ntitle = \"Splunk\"\navailability = \"v2.15+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk saved search results.\"\ngo_file = \"splunk_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches).\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: splunk\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"1\"\n      activationValue: \"10\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n**Parameter list:**\n\n- `host` - Search API host and port. Example: `https://localhost:8089`.\n- `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `\"true\"`, `\"false\"`, Default: `\"false\"`, Optional)\n- `targetValue` - Value to reach to start scaling (This value can be a integer or float).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `savedSearchName` - Name of saved search that returns metric data for scaling.\n- `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`.\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication.\n\n> **Note:**\n>\n> `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API.\n\n**Parameter list:**\n\n- `username` - Splunk username authorized to access the search API.\n- `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`.\n- `password` - Password for supplied `username`. Conflicts with `apiToken`.\n\nThe user will need access to the saved search.\n\n### Examples\n\n### Username/password\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### API Token\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # admin\n  apiToken: <base64 encoded api token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: apiToken\n      name: splunk-creds\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### Full example using Splunk deployment\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: splunkconf\ndata:\n  default.yml: |\n    splunk:\n      conf:\n        - key: savedsearches\n          value:\n            directory: /opt/splunk/etc/users/admin/search/local\n            content:\n              my-saved-search-name:\n                action.email.useNSSubject: 1\n                action.webhook.enable_allowlist: 0\n                alert.track: 0\n                cron_schedule: '*/1 * * * *'\n                dispatch.earliest_time: -15m\n                dispatch.latest_time: now\n                display.general.type: statistics\n                display.page.search.tab: statistics\n                display.visualizations.show: 0\n                enableSched: 1\n                request.ui_dispatch_app: search\n                request.ui_dispatch_view: search\n                search: index=_internal | tail | stats count\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: splunk\nspec:\n  ports:\n    - port: 8000\n      targetPort: web\n      name: web-svc\n    - port: 8089\n      targetPort: 8089\n      name: api-svc\n  selector:\n    app: splunk\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: splunk\n  namespace: default\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: splunk\n  template:\n    metadata:\n      labels:\n        app: splunk\n    spec:\n      containers:\n      - name: splunk\n        image: splunk/splunk:9.2\n        ports:\n          - containerPort: 8000\n            name: web\n          - containerPort: 8089\n            name: api\n        env:\n          - name: SPLUNK_START_ARGS\n            value: --accept-license\n          - name: SPLUNK_PASSWORD\n            value: password\n        volumeMounts:\n          - name: splunkconf-volume\n            mountPath: /tmp/defaults\n      volumes:\n        - name: splunkconf-volume\n          configMap:\n            name: splunkconf\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx\n        ports:\n        - containerPort: 8080\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      unsafeSsl: \"true\"\n      targetValue: \"5\"\n      activationValue: \"5\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n"
  },
  {
    "path": "content/docs/2.18/scalers/sumologic.md",
    "content": "+++\ntitle = \"Sumo Logic\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"Monitoring & Analytics\"\ndescription = \"Scale applications based on Sumo Logic logs searches and metrics queries.\"\ngo_file = \"sumologic_scaler\"\n+++\n\n## Trigger Specification\n\nThis specification describes the `sumologic` trigger that scales based on Sumo Logic logs searches and metrics queries. The scaler supports three different query types:\n\n- **`logs`** - Scale based on Sumo Logic logs query results\n- **`metrics`** - Scale based on single Sumo Logic metrics query results  \n- **`metrics` (multi-query)** - Scale based on multiple combined Sumo Logic metrics queries\n\nHere are examples of the different trigger configurations:\n\n**Logs Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"   # Sumo Logic API endpoint\n    queryType: \"logs\"                   # Type must be \"logs\"\n    query: \"_view=my_view | count\"      # Your Sumo Logic logs query\n    resultField: \"_count\"               # Field to extract value from\n    timerange: \"15m\"                    # Lookback window\n    timezone: \"Asia/Kolkata\"            # Timezone (e.g., Asia/Kolkata)\n    queryAggregator: \"Max\"              # Aggregation method: Latest, Avg, Sum, Count, Min, Max\n    threshold: \"1000\"                   # Threshold for scaling\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Single Metrics Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"\n    queryType: \"metrics\"\n    query: \"metric=cpu.usage | avg\"\n    quantization: \"15s\"\n    rollup: \"Max\"\n    timerange: \"15m\"\n    timezone: \"Asia/Kolkata\"\n    queryAggregator: \"Max\"\n    threshold: \"50\"\n    maxRetries: \"3\"                     # Optional: Maximum retry attempts\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Multi-Metrics Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"\n    queryType: \"metrics\"\n    query.A: \"metric=requests_total | rate\"\n    query.B: \"metric=request_capacity\"\n    query.C: \"(#A / #B) * 100 along service\"\n    resultQueryRowID: \"C\"          # Which query result to extract\n    quantization: \"15s\"\n    rollup: \"Max\"\n    timerange: \"15m\"\n    timezone: \"Asia/Kolkata\"\n    queryAggregator: \"Max\"\n    threshold: \"75\"\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Parameter list:**\n\n**Common Parameters:**\n\n- `host` - Sumo Logic API endpoint URL (Based on your Geo).\n- `queryType` - Type of query. (Values: `logs`, `metrics`)\n- `query` - Sumo Logic query (for single queries).\n- `timerange` - Time range to evaluate the query.\n- `timezone` - Timezone for query execution. (Default: `UTC`, Optional)\n- `queryAggregator` - Aggregation method. (Values: `Latest`, `Avg`, `Sum`, `Count`, `Min`, `Max`, Default: `Avg`, Optional)\n- `threshold` - Target value for scaling.\n- `maxRetries` - Maximum number of retry attempts for API requests. (Default: `3`, Optional)\n\n**Logs Query Specific Parameters:**\n\n- `resultField` - Field from query results to extract the scaling metric. (Required when `queryType` is `logs`)\n- `logsPollingInterval` - Polling interval for log search job. (Default: `1s`, Optional)\n\n**Metrics Query Specific Parameters:**\n\n- `quantization` - Granularity of data points. (Required when `queryType` is `metrics`)\n- `rollup` - Metrics rollup type. (Values: `Avg`, `Sum`, `Min`, `Max`, `Count`, Default: `Avg`, Optional)\n\n**Multi-Metrics Query Specific Parameters:**\n\n- `query.A`, `query.B`, `query.C` etc - Multi-stage queries, where later queries can refer to earlier ones. (Required for multi-metrics queries)\n- `resultQueryRowID` - Which final query (`A`, `B`, `C`, etc.) to use for scaling. (Required for multi-metrics queries)\n\n## Authentication Parameters\n\nYou must configure a `TriggerAuthentication` resource to authenticate with Sumo Logic.\n\n**Prerequisites:**\n- A Sumo Logic Access ID and Access Key\n\nAuthentication is handled through a Kubernetes `Secret` combined with a `TriggerAuthentication`:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: sumologic-auth-secret\ndata:\n  accessID: <base64-encoded-accessID>\n  accessKey: <base64-encoded-accessKey>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-sumologic\nspec:\n  secretTargetRef:\n    - parameter: accessID\n      name: sumologic-auth-secret\n      key: accessID\n    - parameter: accessKey\n      name: sumologic-auth-secret\n      key: accessKey\n```\n\n### Example\n\nHere is a complete example that demonstrates autoscaling based on Sumo Logic logs query:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: sumologic-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: sumologic\n    metadata:\n      host: \"https://api.sumologic.com\"\n      queryType: \"logs\"\n      query: \"_view=error_logs | count\"\n      resultField: \"_count\"\n      timerange: \"5m\"\n      threshold: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-sumologic\n```\n\n### Notes\n\n- `pollingInterval` controls how often KEDA polls Sumo Logic.\n- `cooldownPeriod` controls how long KEDA waits before scaling down.\n- `MetricType:` The scaler supports both `AverageValue` and `Value` metric types.\n- Ensure that the Sumo Logic user has **appropriate access** to the queries being executed.\n\n"
  },
  {
    "path": "content/docs/2.18/scalers/temporal.md",
    "content": "+++\ntitle = \"Temporal\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Temporal task queue.\"\ngo_file = \"temporal_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `temporal` trigger that scales based on a Temporal task queue.\n\n```yaml\ntriggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n      queueTypes: workflow # optional\n      buildId: 1.0.0 # optional\n      selectAllActive: \"false\" # optional\n      selectUnversioned: \"false\" # optional\n      minConnectTimeout: \"5\" # optional\n      unsafeSsl: \"false\" # optional\n      tlsServerName: \"custom-tls-servername\" # optional\n```\n\n**Parameter list:**\n\n- `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `<hostname>:<port>`. (Required)\n- `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional)\n- `namespace` - The namespace of the temporal service. (Default:`default`, Optional)\n- `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found  [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional)\n- `taskQueue` - This parameter specifies the task queue name. (Required)\n- `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional)\n- `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional)\n- `selectAllActive` - Include all active versions (Default:`false`, Optional)\n- `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional)\n- `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional)\n- `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional)\n- `tlsServerName` - The custom tls server name (Optional)\n\n> 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero.\n  This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog.\n  Consequently, scaling to zero could result in undesirable behavior,\n  such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA).\n  By fine-tuning the configurations, you can prevent premature scaling to zero,\n  ensuring that resources remain available for in-flight tasks or workloads with minimal throughput.\n\n\n**Authentication Parameters:**\n\nTemporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication:\n\n- `apiKey` - API key for authentication with temporal cloud. (Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: temporal-secret\n  namespace: default\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-temporal\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: apiKey\n    name: temporal-secret\n    key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: workload-scaledobject\n  pollingInterval: 5\n  cooldownPeriod:  10\n  minReplicaCount: 0\n  maxReplicaCount: 5\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 10\n  triggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n    authenticationRef:\n      name: keda-trigger-auth-temporal\n```\n"
  },
  {
    "path": "content/docs/2.18/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.18/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.19/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\ndescription = \"How you can start with KEDA as new user\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. \n\nUse the navigation bar on the left to learn more about KEDA's architecture  and how to deploy and use KEDA.\n\n## Where to go\n\nWhat is your involvement with KEDA?\n\n| Role                      | Documentation                                                                                                                                                |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| User                      | This documentation is for users who want to deploy KEDA to scale Kubernetes.                                                                                 |\n| Core Contributor          | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda).                                                         |\n| Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). |\n| Other Contributor         | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers.            |\n"
  },
  {
    "path": "content/docs/2.19/addons/_index.md",
    "content": "+++\ntitle = \"Add-ons\"\nweight = 3\n+++\n\nAdd-ons extend KEDA with support for specific use cases beyond the built-in scalers.\n\n## HTTP Add-on\n\nThe [HTTP Add-on](/http-add-on/latest/) enables autoscaling of HTTP-based workloads.\nIt intercepts incoming HTTP requests and scales the target workload based on request volume.\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optionqal\n```\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n**Regional STS endpoints**\n\n- If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace.  \n- If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses).\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: <SERVICE_ACCOUNT_NAME>\n  namespace: <NAMESPACE>\n  annotations:\n    eks.amazonaws.com/role-arn: <YOUR_IRSA_ROLE_ARN>\n    # Required for regional STS endpoints (e.g. eu-west-1)\n    eks.amazonaws.com/sts-regional-endpoints: \"true\"\n ```\n\n### When do you need regional STS endpoints?\n\nBy default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`).  \nSome regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`).  \n\nIf you see errors like:\n\n```\nAccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n```\n\nwhile your IAM trust policy looks correct, you likely need to enable regional endpoints with:\n\n```yaml\nannotations:\n  eks.amazonaws.com/sts-regional-endpoints: \"true\"\n```\n\n👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nAttach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/bound-service-account-token.md",
    "content": "+++\ntitle = \"Bound service account token\"\n+++\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n## Permissions for KEDA to request service account tokens\n\nBy default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster.\n\nTo allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource.\n\nHere's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account.\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator\n  namespace: my-namespace # Replace with the namespace of the service account\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - my-service-account # Replace with the name of the service account\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding\n  namespace: my-namespace # Replace with the namespace of the service account\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda # Assuming the keda-operator service account is in the keda namespace\n```\n\nAfter applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API.\n\n### Usage in keda-charts\n\nIf you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example:\n\n```yaml\n# values.yaml\npermissions:\n  operator:\n    restrict:\n      serviceAccountTokenCreationRoles:\n      - name: myServiceAccount\n        namespace: myServiceAccountNamespace\n```\n\nThis will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator-myServiceAccount\n  namespace: myServiceAccountNamespace\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - myServiceAccount\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding-myServiceAccount\n  namespace: myServiceAccountNamespace\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator-myServiceAccount\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda\n```\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/file-path.md",
    "content": "+++\ntitle = \"File path\"\n+++\n\nYou can read authentication parameters from files mounted in the KEDA operator pod using the `filePath` option. This feature requires the KEDA operator to be configured with a root path for file access.\n\n## Security Constraints\n\nThe `filePath` feature has important security constraints:\n\n- **Requires root path configuration** - The KEDA operator must be started with `--filepath-auth-root-path` to define the allowed directory\n- **Path validation** - All file paths are validated to ensure they resolve within the configured root path, preventing access to sensitive system files like service account tokens\n- **Relative paths** - The `filePath` in `ClusterTriggerAuthentication` is treated as a relative path under the configured root path\n\n## Operator Configuration\n\nThe KEDA operator requires a command-line argument to enable file-based authentication:\n\n```bash\n--filepath-auth-root-path=/path/to/allowed/files\n```\n\nThis path should point to a directory where credential files are mounted. The operator will only read files from within this directory.\n\n## Example\n\nFirst, ensure the KEDA operator has the root path configured. Then create a `ClusterTriggerAuthentication` referencing files:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: file-based-auth\nspec:\n  filePath:\n    - parameter: apiKey           # Required - Defined by the scale trigger\n      path: credentials/api-key   # Required - Path relative to filepath-auth-root-path\n```\n\n**Assumptions:**\n- The path is relative to the `--filepath-auth-root-path` configured for the KEDA operator\n- The credential file exists at `{filepath-auth-root-path}/credentials/api-key`\n- The file contains the raw credential value (not JSON encoded)\n- The file path should match the actual file name, including any extension if present (e.g., `credentials/api-key.txt` if the file is named `api-key.txt`)\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method. There's multiple methods for authentication; For kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) or provide the serviceAccountName that can authenticate to kubernetes in the namespace of the ScaledObject/ScaledJob resource (usually `default`). If using serviceAccountName make sure to grant KEDA Operator `create serviceaccounts/token` permissions. This is set in the helm chart via `permissions.operator.restrict.allowAllServiceAccountTokenCreation=true` For token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional. Authenticate to vault via a supplied token\n    serviceAccount: {path-to-service-account-file}            # Optional. Authenticate to vault via JWT token in keda operator pod\n    serviceAccountName: {service-account-name-for-auth}       # Optional. Requires serviceaccounts/token create permissions. Authenticate to vault via JWT token from service account in ScaledObject/ScaledJob's namespace\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.19/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.19/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests.\n\nIt’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup.\n\n## How KEDA works\n\nKEDA monitors external event sources and adjusts your app’s resources based on the demand. Its main components work together to make this possible:\n\n* **KEDA Operator** keeps track of event sources and changes the number of app instances up or down, depending on the demand.\n* **Metrics Server** provides external metrics to Kubernetes’ HPA so it can make scaling decisions.\n* **Scalers** connect to event sources like message queues or databases, pulling data on current usage or load.\n* **Custom Resource Definitions (CRDs)** define how your apps should scale based on triggers like queue length or API request rates.\n\nIn simple terms, KEDA listens to what’s happening outside Kubernetes, fetches the data it needs, and scales your apps accordingly. It’s efficient and integrates well with Kubernetes to handle scaling dynamically.\n\n## KEDA Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch.png)\n\nExternal events, like an increase in queue messages, trigger the **ScaledObject**, which sets the scaling rules. The **Controller** handles the scaling, while the **Metrics Adapter** sends data to the HPA for real-time scaling decisions. **Admission Webhooks** ensure your configuration is correct and won’t cause problems.\n\nThis setup lets Kubernetes adjust resources automatically based on what’s happening outside, keeping things efficient and responsive.\n\n## KEDA Custom Resources (CRDs)\n\nKEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior:\n\n* **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works.\n* **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics.\n* **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials.\n\nThese CRDs give you control over scaling while keeping your apps secure and responsive to demand.\n\n## Scaling Deployments, StatefulSets, and Custom Resources\n\nKEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs.\n\n### Scaling Deployments and StatefulSets\n\nWith KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand.\n\nDeployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand.\n\n### Scaling Custom Resources\n\nKEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically.\n\n### Scaling Jobs\n\nKEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed.\n\n### Authentication\n\nKEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe.\n\n### External Scalers\n\nKEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly.\n\n### Consuming Raw Scaler Metrics Externally\n\nKEDA also allows consuming the internal metrics (coming from internal or external scalers) to interested 3rd parties. This feature is exposed using gRPC server stream API and needs to be first enabled by setting `RAW_METRICS_GRPC_PROTOCOL` to \"`enabled`\". Then one can subscribe to a metric identified by ScaledObject/ScaledJob name, namespace and trigger name using any gRPC client (example with [grpcurl](https://github.com/kedacore/keda/pull/7093#issuecomment-3333530716)).\n\nYou can control when raw metrics are sent using the `RAW_METRICS_MODE` environment variable:\n\n* `all` or `\"\"` (empty): Sends all raw metrics, both when the metrics server requests them (HPA) and during the regular polling interval of each ScaledObject or ScaledJob. This is the default behavior.\n* `hpa`: Sends raw metrics only when the Kubernetes metrics server explicitly requests metrics for a ScaledObject. This means metrics are sent in response to HPA queries, not on a regular schedule.\n* `pollinginterval`: Sends raw metrics only during the polling interval of each ScaledObject or ScaledJob. In this mode, metrics are pushed out at each polling cycle, regardless of HPA requests.\n* Any unknown value will default to the `all` mode.\n\n### Admission Webhooks\n\nKEDA uses admission webhooks to validate your scaling setup. They ensure your configuration is correct, like preventing multiple ScaledObjects from targeting the same app. This reduces errors and makes scaling smoother.\n"
  },
  {
    "path": "content/docs/2.19/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.19/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure-workload | aws | aws-eks | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  filePath:                                                               # Optional. Define only for ClusterTriggerAuthentication; not supported for TriggerAuthentication.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    path: {relative-path-to-file}                                         # Required. Relative to --filepath-auth-root-path.\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                              # Required.\n      path: {hashicorp-vault-secret-path}                                 # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure-workload                                            # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n      secretKey: {aws-secret-key}                                         # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### File(s)\n\n> **Note:** This feature requires the KEDA operator to be configured with `--filepath-auth-root-path`.\n\nYou can read authentication parameters from files mounted in the KEDA operator pod. This is useful when credentials are provided via init containers or sidecars that write to a shared volume.\n\nThe `filePath` option is only available for `ClusterTriggerAuthentication`, not for namespaced `TriggerAuthentication`.\n\n```yaml\nfilePath:                                 # Optional.\n  - parameter: apiKey                     # Required - Defined by the scale trigger\n    path: credentials/api-key             # Required - Path relative to filepath-auth-root-path\n```\n\n**Security constraints:**\n- The path is validated to ensure it resolves within the configured `--filepath-auth-root-path`\n- Access to sensitive paths like `/var/run/secrets/kubernetes.io/serviceaccount/` is blocked\n- Only `ClusterTriggerAuthentication` can use this authentication method\n\n**Assumptions:**\n- The KEDA operator must be started with `--filepath-auth-root-path=/path/to/allowed/files`\n- The credential file exists at `{filepath-auth-root-path}/{path}`\n- The file contains the raw credential value\n\n### Bound service account token(s)\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure-workload | aws | aws-eks | gcp               # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.19/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec).\n> Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.19/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\nThis page describes the deployment scaling behavior of KEDA. \n\n# Specification\n\nSee the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below.\n\n# Scaling objects\n\n## Scaling Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## Scaling Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n# Features\n\n## Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval.\n\nEnabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n## Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledObject` definition:\n\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`.\n\nAdditionally, we provide the ability to temporarily pause scale in on a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-scale-in: \"true\"\n```\n\nWhen the annotation is set, KEDA will update the generated HPA to disable scale in (via setting the HPA's Scale Down Select Policy to Disabled) and if the service has scale to zero configured, will block scale to zero. When the annotation is unset, the scale down behavior on the HPA will be restored to its original configuration and, if configured, scale to zero will be unblocked. \n\nConversely, we provide the ability to temporarily pause scale out on a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-scale-out: \"true\"\n```\n\nWhen the annotation is set, KEDA will update the generated HPA to disable scale out (via setting the HPA's Scale Up Select Policy to Disabled) and if the service has scale to zero configured, will block scale from zero. When the annotation is unset, the scale up behavior on the HPA will be restored to its original configuration and, if configured, scale up from zero will be unblocked. \n\nIf you want disable scaling in both directions, we recommend you use the `autoscaling.keda.sh/paused` as that will stop the scale loop and paused queries against the ScaledObject's configured scaler.\n\n## Scaling Modifiers\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n\n## Activating and Scaling thresholds\n\nKEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Forcing Activation\n\nWe provide the ability to temporarily force the activation of a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/force-activation: \"true\"\n```\n\nWhen the annotation is set, KEDA will treat all configured scalers as active. If the scalers were previously not active, KEDA will scale the service up from 0.\n\nWhen the annotation is subsequently unset, the state of the scaler activation will revert to being computed from the state of the scaler metrics.\n\n## Transferring ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disabling validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n### Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n#### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n#### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](./scaling-jobs).\n\n## Excluding labels from being propagated to the HPA\n\nYou can exclude specific labels from being propagated to the generated HPA object by using the `scaledobject.keda.sh/hpa-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded.\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/hpa-excluded-labels: \"foo.bar/environment,foo.bar/version\"\n  labels:\n    team: backend\n    foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5\n    foo.bar/version: \"1\"\n"
  },
  {
    "path": "content/docs/2.19/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\nThis page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below.\n\n\n# Overview\n\nAs an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n\n# Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nTo reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: false\n```\n\n\n## Example\n\nAn example configuration for autoscaling jobs using a RabbitMQ scaler is given below. \n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n# Excluding labels from being propagated to the Job\n\nYou can exclude specific labels from being propagated to the generated Job object by using the `scaledjob.keda.sh/job-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded.\n\n```yaml\nmetadata:\n  annotations:\n    scaledjob.keda.sh/job-excluded-labels: \"foo.bar/environment,foo.bar/version\"\n  labels:\n    team: backend\n    foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5\n    foo.bar/version: \"1\"\n"
  },
  {
    "path": "content/docs/2.19/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.19/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nKEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization.\n\nUsing **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster.\n\nEach method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment.\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.30 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Prerequisites\n\nTo deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features.\n\nIf you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease.\n\n### Installing\n\n1. To deploy KEDA using Helm, first add the official KEDA Helm repository:\n\n    ```sh\n   helm repo add kedacore https://kedacore.github.io/charts  \n   helm repo update\n    ```\n\n2. Install `keda` by running:\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n    This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods:\n\n    ```sh\n    kubectl get pods -n keda\n    ```\n\nTo deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps:\n\n1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version.\n2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions:\n\n    ```sh\n    kubectl apply -f keda-2.xx.x-crds.yaml\n    ```\n\n    Replace `2.xx.x` with the specific version number you downloaded.\n\nBy deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process.\n> 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues.\n\nDeploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments.\n\n### Uninstalling\n\nTo uninstall KEDA, use the following Helm command:\n\n```sh\nhelm uninstall keda –namespace keda\n```\n\nThis command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run:\n\n```sh\nkubectl delete namespace keda\n```\n\nUninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version.\n\nYou can remove finalizers with the following command:\n\n```sh\nkubectl patch scaledobject <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\nkubectl patch scaledjob <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\n```\n\nReplace \\<*resource-name*\\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster.\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Prerequisites\n\nBefore deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access.\n\nIf you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub.\n\n### Installing\n\nTo deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed.\n\nSearch for \"KEDA\" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace.\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\nUsing Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment.\n\n> 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository:\n> \n> [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator)\n> \n> This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments.\n> \n> For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful:\n>\n> \\- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator.\n> \n> \\- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster.\n> \n> \\- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project.\n\n### Uninstalling\n\nTo uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster.\n\nIf you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks.\n\n## Deploying KEDA using the YAML files {#yaml}\n\n### Prerequisites\n\nBefore deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster.\n\n### Installing\n\nOnce the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0-core.yaml\n```\n\nAlternatively you can download the file and deploy it from the local path:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.19.0.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.19.0-core.yaml\n```\n\nThe `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740).\n\n> 💡 **NOTE:**  If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally:\n>\n> ```sh\n> git clone https://github.com/kedacore/keda && cd keda\n> \n> VERSION=2.19.0 make deploy\n> ```\n>\n> This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization.\n\nAfter applying the YAML, verify the deployment by checking the KEDA namespace:\n\n```sh\nkubectl get pods -n keda\n```\n\nDeploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates.\n\n### Uninstalling\n\nIf you installed KEDA using the released YAML files, you can uninstall it by running the following commands:\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.19.0/keda-2.19.0-core.yaml\n```\n\nIf you downloaded the files locally, uninstall with:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.19.0.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.19.0-core.yaml\n```\n\nFor users who cloned the KEDA GitHub repository, navigate to the cloned directory and use:\n\n```sh\nVERSION=2.19.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Prerequisites\n\nBefore deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`).\n\nAdditionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons:\n\n* **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration.\n* **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation.\n\n### Installing\n\nTo install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on.\n\n1. Enable Helm and DNS Add-ons (if not already enabled):\n\n   ```sh\n   microk8s enable dns helm3use\n   ```\n\n2. Add the KEDA Helm Repository:\n\n   ```sh\n   microk8s helm3 repo add kedacore https://kedacore.github.io/charts\n   \n   microk8s helm3 repo update\n   ```\n\n3. Install KEDA Using Helm.\n\n   Deploy KEDA into your MicroK8s cluster by running:\n\n   ```sh\n   microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace\n   ```\n\n4. Verify the Installation.\n\n   Check that KEDA is running by listing the pods in the keda namespace:\n\n   ```sh\n   microk8s kubectl get pods -n keda\n   ```\n\nThis approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development.\n\n### Uninstalling\n\nTo uninstall KEDA from your MicroK8s environment, disable the KEDA add-on:\n\n```sh\nmicrok8s disable keda\n```\n\nThis command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation.\nIf you deployed KEDA using Helm, uninstall it with:\n\n```sh\nmicrok8s helm3 uninstall keda --namespace keda\n```\n\nAfter running these commands, KEDA will be fully removed from your MicroK8s setup.\n\n## Getting Started with KEDA: A Simple Example\n\nTo help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This \"Hello KEDA\" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality.\n\nBefore starting, ensure you have the following:\n\n* **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service.\n* **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster.\n* **KEDA Installed**: KEDA should be installed in your cluster.\n\n### Step 1: Deploy a Sample Application\n\nWe'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server.\n\n1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`:\n\n   ```yaml\n   apiVersion: apps/v1\n   kind: Deployment\n   metadata:\n      name: http-app\n   spec:\n      replicas: 1\n      selector:\n         matchLabels:\n            app: http-app\n      template:\n         metadata:\n            labels:\n               app: http-app\n         spec:\n            containers:\n            - name: http-app\n              image: hashicorp/http-echo\n              args:\n                 - \"-text=Hello, KEDA!\"\n              ports:\n                 - containerPort: 5678\n      ```\n\n2. **Apply the Deployment**: Run the following command to create the deployment:\n\n   ```sh\n   kubectl apply -f deployment.yaml\n   ```\n\n### Step 2: Expose the Application\n\nTo access the application, we'll create a Service.\n\n1. **Create a Service Manifest**: Save the following YAML as `service.yaml`:\n\n   ```yaml\n   apiVersion: v1\n   kind: Service\n   metadata:\n      name: http-app-service\n   spec:\n      selector:\n         app: http-app\n      ports:\n         - protocol: TCP\n           port: 80\n           targetPort: 5678\n      type: LoadBalancer\n   ```\n\n2. **Apply the Service**: Run the following command to create the service:\n\n   ```sh\n   kubectl apply -f service.yaml\n   ```\n\n3. **Retrieve the External IP**: After a few moments, retrieve the external IP address:\n\n   ```sh\n   kubectl get service http-app-service\n   ```\n\n### Step 3: Create a ScaledObject\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\n\n1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`:\n\n   ```yaml\n   apiVersion: keda.sh/v1alpha1\n   kind: ScaledObject\n   metadata:\n      name: http-app-scaledobject\n   spec:\n      scaleTargetRef:\n         name: http-app\n      minReplicaCount: 1\n      maxReplicaCount: 10\n      triggers:\n         - type: prometheus\n           metadata:\n              serverAddress: http://prometheus-server.default.svc.cluster.local:9090\n              threshold: '5'\n              query: sum(rate(http_requests_total[1m])) \n   ```\n\n   > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed.\n2. **Apply the ScaledObject**: Run the following command to create the ScaledObject:\n\n   ```sh\n   kubectl apply -f scaledobject.yaml   \n   ```\n\n### Step 4: Test the Scaling Behavior\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\nTo observe KEDA's scaling in action:\n\n1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP:\n\n   ```sh\n   hey -z 1m -c 10 http://<EXTERNAL-IP>\n   ```\n\n   Replace `<EXTERNAL-IP>` with the external IP address obtained earlier.\n2. **Monitor Scaling:** Run the following command to watch the scaling behavior:\n\n   ```sh\n   kubectl get pods -w\n   ```\n\n   You should see the number of pods increase as the load increases and decrease when the load subsides.\n\n### Cleanup\n\nAfter completing the exercise, clean up the resources:\n\n   ```sh\n   kubectl delete -f scaledobject.yaml\n   kubectl delete -f service.yaml\n   kubectl delete -f deployment.yaml\n   ```\n\nThis example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events.\n"
  },
  {
    "path": "content/docs/2.19/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.19/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.19/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.19/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n> Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.19/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.19/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance and requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance and requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](../reference/events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.19/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n\n### Cache Miss with Fallback to Direct Client for ScaledObject\n\nWhen validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`:\n```\n--cache-miss-to-direct-client=true\n```\nThis will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API.\n\n\n## Custom Validations using Kubernetes ValidatingAdmissionPolicy\n\n> ⚠️ FEATURE STATE: Kubernetes v1.30 [stable]\n\nKubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).\n\nHere is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10):\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-keda-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"keda.sh\"]\n      apiVersions: [\"v1alpha1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"scaledobjects\"]\n  validations:\n    - expression: \"object.spec.maxReplicaCount <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-keda-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-keda-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```\n\nSince KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas:\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-apps-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"apps\"]\n      apiVersions: [\"v1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"deployments\", \"replicasets\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-hpa-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"autoscaling\"]\n      apiVersions: [\"v2\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"horizontalpodautoscalers\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-apps-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-apps-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-hpa-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-hpa-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```"
  },
  {
    "path": "content/docs/2.19/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 When a CloudEventSource resource is created, KEDA continues to emit Kubernetes Events and will additionally emit CloudEvents for the supported event types listed in this document.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                                 | Scenario Description                                                                                                          |\n|--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|\n| `keda.scaledobject.ready.v1`               | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False`   |\n| `keda.scaledobject.failed.v1`              | If the check validation for a ScaledObject fails                                                                              |\n| `keda.scaledobject.removed.v1`             | When a ScaledObject is deleted                                                                                                |\n| `keda.scaledobject.paused.v1`              | When a ScaledObject is paused                                                                                                 |\n| `keda.scaledobject.unpaused.v1`            | When a ScaledObject is unpaused                                                                                               |\n| `keda.scaledjob.ready.v1`                  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`      |\n| `keda.scaledjob.failed.v1`                 | If the check validation for a ScaledJob fails                                                                                 |\n| `keda.scaledjob.removed.v1`                | When a ScaledJob is deleted                                                                                                   |\n| `keda.scaledjob.paused.v1`                 | When a ScaledJob is paused                                                                                                    |\n| `keda.scaledjob.unpaused.v1`               | When a ScaledJob is unpaused                                                                                                  |\n| `keda.scaledjob.rolloutcleanup.started.v1` | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob                                                |\n| `keda.scaledjob.rolloutcleanup.completed.v1` | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob                                            |\n| `keda.scaledjob.rolloutcleanup.failed.v1`  | When KEDA fails to delete a Job owned by the previous version of a ScaledJob                                                  |\n| `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created                                                              |\n| `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated                                                                           |\n| `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted                                                                           |\n| `keda.authentication.clustertriggerauthentication.created.v1` | On the first time a ClusterTriggerAuthentication is created                                                |\n| `keda.authentication.clustertriggerauthentication.updated.v1` | When a ClusterTriggerAuthentication is updated                                                             |\n| `keda.authentication.clustertriggerauthentication.removed.v1` | When a ClusterTriggerAuthentication is deleted                                                             |"
  },
  {
    "path": "content/docs/2.19/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.19 | v1.32 - v1.34 |\n| v2.18 | v1.31 - v1.33 |\n| v2.17 | v1.30 - v1.32 |\n| v2.16 | v1.29 - v1.31 |\n| v2.15 | v1.28 - v1.30 |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n\n## Restrict Custom Resources\n\nAs KEDA supports scaling any workload inside the cluster, there is a non restrictive RBAC rule applied to all the cluster\n\n```yaml\n- apiGroups:\n    - *\n  resources:\n    - */scale\n  verbs:\n    - get\n    - list\n    - patch\n    - update\n    - watch\n- apiGroups:\n    - *\n  resources:\n    - *\n  verbs:\n    - get\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces as well as any workload type accross all the cluster.\n\nTo limit this permissions, you can review and adapt the RBAC generated by KEDA based on your necessities to only grant those permissions that you intentionally want to grant.\n\n> Note: If you are using KEDA's helm chart, you can totally disable Custom Resources via `rbac.enabledCustomScaledRefKinds` or limit the current `*` setting only your needed resources via `rbac.scaledRefKinds`.\n\n> It is always recommended to review the final generated role for KEDA components to ensure no broad permissions are assigned if the Helm template was customized. To quickly verify typical cases like blocked access to secrets, any tool used to analyze K8s RBAC can be used (e.g. https://github.com/aquasecurity/kubectl-who-can).\n\n\n## Logs\n\nKEDA uses zap to emit logs. The following flags can be used to configure logging behavior in both the metrics-apiserver and operator:\n\n- zap-encoder: Zap log encoding (one of `json` or `console`). Default is `console`\n- zap-log-level: Zap Level to configure the verbosity of logging. Can be one of `debug`, `info`, `error`,\n  or any integer value > 0 which corresponds to custom debug levels of increasing verbosity\". Default is `info`.\n- zap-time-encoding: Zap time encoding (one of `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano`),\n  Defaults is `rfc3339`.\n"
  },
  {
    "path": "content/docs/2.19/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (external metrics only):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.19/operate/schema.md",
    "content": "+++\ntitle = \"Schema\"\ndescription = \"Specification & generation of KEDA scalers' schema\"\nweight = 100\n+++\n\n## Scaler Schema\n\nKEDA provides a separate scaler's schema for third-party usage ([scalers-metadata-schema.yaml](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.yaml)/[scalers-metadata-schema.json](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.json)). The schema file will keep updating according to the scaler's refactor.\n\n*Notice: The schema file still lacks some of the scalers. It will be completed once all scalers are refactored to use the new declarative scaler config.\n\n## Specification\n\nHere is a the schema of the scalers:\n\n```\nkedaVersion: main \nschemaVersion: 1\nscalers:\n    - type: activemq\n      parameters:\n        - name: managementEndpoint\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: destinationName\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: brokerName\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: username\n          type: string\n          metadataVariableReadable: true\n          envVariableReadable: true\n          triggerAuthenticationVariableReadable: true\n        - name: password\n          type: string\n          metadataVariableReadable: true\n          envVariableReadable: true\n          triggerAuthenticationVariableReadable: true\n        - name: corsHeader\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: restAPITemplate\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: targetQueueSize\n          type: string\n          default: \"10\"\n          metadataVariableReadable: true\n        - name: activationTargetQueueSize\n          type: string\n          default: \"0\"\n          metadataVariableReadable: true\n    - type: apache-kafka\n      parameters:\n        - name: bootstrapServers\n        ...\n\n```\n\n**Metadata field's property detail:**\n| Property  | Description \n|--------------|------------\n| name         | the name of the field\n| type         | type is the variable type of the field\n| optional     | optional is a boolean that indicates if the field is optional\n| default      | default is the default value of the field \n| allowedValue | allowedValue is a list of allowed values for the field\n| deprecated   | deprecated is a string that indicates if the field is deprecated\n| deprecatedAnnounce | deprecatedAnnounce is a string that indicates the deprecation message\n| separator | separator is the symbol that separates the value of the field if the value is a list string\n| exclusiveSet | exclusiveSet is a list of fields that are exclusive with the field\n| rangeSeparator | rangeSeparator is the symbol that indicates the range of the field\n| metadataVariableReadable | metadataVariableReadable is a boolean that indicates if the field can be read from the environment\n| envVariableReadable | envVariableReadable is a boolean that indicates if the field can be read from the environment\n| triggerAuthenticationVariableReadable | triggerAuthenticationVariableReadable is a boolean that indicates if the field can be read from the trigger authentication\n\n## Generation\n\nThere are two ways to generate scaler schemas:\n\n1. Run the GO file in the schema folder directly\n```\ngo run schema/generate_scaler_schema.go\nparameters:\n  --keda-version string                Set the version of current KEDA in schema. (default \"1.0\")\n  --kubeconfig string                  Paths to a kubeconfig. Only required if out-of-cluster.\n  --output-file-path string            scaler-metadata-schemas.yaml output file path. (default \"./\")\n  --scalers-builder-file buildScaler   The file that exists buildScaler func. (default \"../pkg/scaling/scalers_builder.go\")\n  --scalers-files-dir string           The directory that exists all scalers' files. (default \"../pkg/scalers\")\n  --specify-scaler string              Specify scaler name.\n```\n\n2. Use makefile\n```\nmake  generate-scaler-schemas\nenv variables:\n    OUTPUT_FILE_PATH          scaler-metadata-schemas.yaml output file path. (default \"./\")\n    SCALERS_BUILDER_FILE   The file that exists buildScaler func. (default \"../pkg/scaling/scalers_builder.go\")\n    SCALERS_FILES_DIR           The directory that exists all scalers' files. (default \"../pkg/scalers\")\n```\n\n SCALERS_BUILDER_FILE ?= \"pkg/scaling/scalers_builder.go\" \n SCALERS_FILES_DIR ?= \"pkg/scalers\" \n OUTPUT_FILE_PATH ?= \"schema/\"\n"
  },
  {
    "path": "content/docs/2.19/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAdditionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources.\n\nExample use case:\n- When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources.\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory.  Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`.\n"
  },
  {
    "path": "content/docs/2.19/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Kubernetes Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)\n"
  },
  {
    "path": "content/docs/2.19/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectUpdateFailed`            | `Warning` | When KEDA fails to update status for a ScaledObject                                                                         |\n| `ScaledJobUpdateFailed`               | `Warning` | When KEDA fails to update status for a ScaledJob                                                                            |\n| `ScaledObjectPaused`                  | `Normal`  | When a ScaledObject is paused                                                                                               |\n| `ScaledObjectUnpaused`                | `Normal`  | When a ScaledObject is unpaused                                                                                             |\n| `ScaledObjectFallbackActivated`       | `Normal`  | When a ScaledObject fallback becomes active                                                                                 |\n| `ScaledObjectFallbackDeactivated`     | `Normal`  | When a ScaledObject fallback becomes inactive                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `ScaledJobPaused`                     | `Normal`  | When a ScaledJob is paused                                                                                                  |\n| `ScaledJobUnpaused`                   | `Normal`  | When a ScaledJob is unpaused                                                                                                |\n| `ScaledJobPauseFailed`                | `Warning` | When KEDA fails to pause a ScaledJob                                                                                        |\n| `ScaledJobRolloutCleanupStarted`      | `Normal`  | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob                                              |\n| `ScaledJobRolloutCleanupCompleted`    | `Normal`  | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob                                            |\n| `ScaledJobRolloutCleanupFailed`       | `Warning` | When KEDA fails to delete a Job owned by the previous version of a ScaledJob                                                |\n| `ScaledJobActive`                     | `Normal`  | When a ScaledJob becomes active (triggers are active and scaling is performed)                                              |\n| `ScaledJobInactive`                   | `Normal`  | When a ScaledJob becomes inactive (triggers are not active and scaling is not performed)                                    |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAMetricSourceFailed`              | `Warning` | When a scaler fails as a metric source for custom formula                                                                   |\n| `KEDAScalerInfo`                      | `Normal`  | When a Scaler contains deprecated field                                                                                     |\n| `KEDAScalerInfo`                      | `Warning` | When a Scaler contains unexpected parameter (disabled by default, enable with `KEDA_CHECK_UNEXPECTED_SCALERS_PARAMS`)       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `KEDAJobCreateFailed`                 | `Warning` | When KEDA fails to create a Job for a ScaledJob                                                                             |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationUpdated`        | `Normal`  | When a TriggerAuthentication is updated                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationUpdated` | `Normal`  | When a ClusterTriggerAuthentication is updated                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.19/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_19\" >}}\n"
  },
  {
    "path": "content/docs/2.19/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## gRPC Remote Procedure Calls (gRPC)\n\ngRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.19/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n**eager**\nWhen adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.\n\nFor example, let's assume we configure a ScaledJob in a cluster as below:\n```yaml\n  ###\n  # A job that runs for a minimum of 3 hours.\n  ###\n  pollingInterval: 10 # Optional. Default: 30 seconds\n  maxReplicaCount: 10 # Optional. Default: 100\n  triggers:\n    - type: rabbitmq\n      metadata:\n        queueName: woker_queue\n        hostFromEnv: RABBITMQ_URL\n        mode: QueueLength\n        value: \"1\"\n```\nWe send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.\n\nWith the `default` scaling strategy, we are supposed to see the metrics changes in the following table:\n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 3          |\n\n\nIf we switch to `eager`, the result becomes: \n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 6          |\n\nWe can identify the difference in their final states.\n\n\nYou may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.19/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n    behavior: {kind-of-behavior}                            # Optional. Default: \"static\"\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N.\n\nIf you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly.\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n    behavior: \"static\"                               # Optional. Default: \"static\"\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nFallback is supported for all triggers of both `Value` and `AverageValue` metric types, except CPU & memory triggers. It's also only supported by `ScaledObjects`, not `ScaledJobs`.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula for `AverageValue` metrics:\n```\ntarget metric value * fallback replicas\n```\nFor `Value` metrics it's using the formula:\n```\ntarget metric value * fallback replicas / current ready replicas\n```\n\nThese formulas offset the HPA's calculations and will cause it to scale the deployment to the specified number of fallback replicas.\n\n## fallback.behavior\n\nThe `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used.\n\n#### `static` behavior\nWhen `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'.\n\n#### `currentReplicas` behavior\nWhen using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'.\n\n#### `currentReplicasIfHigher` behavior\nWhen using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'.\n\n#### `currentReplicasIfLower` behavior\nWhen using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'.\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n          tolerance: 0.1                          # requires Kubernetes v1.33 or newer and feature gate \"HPAConfigurableTolerance\"\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n#### horizontalPodAutoscalerConfig.behavior tolerance\n\nAs of Kubernetes v1.34 the `tolerance` field can be specified under the HPA behavior policy `scaleUp` and `scaleDown` sections. The field applies a tolerance thresholds for scaling decisions, allowing you to specify different behavior for scale-up and scale-down operations. This field was in alpha release under Kubernetes v1.33, which can be enabled through the Kubernetes `HPAConfigurableTolerance` feature gate. As of Kubernetes v1.34, this field has graduated to beta release and is specifiable by default.\n\n### scalingModifiers\n\nIf defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional).\n\nThere is one important exception to the activation target for scaling modifiers and that is [external push scalers](../concepts/external-scalers). These scalers can implement `StreamIsActive` gRPC method which pushes activation status to KEDA directly, regardless of what the metric value and activation target is.\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.19/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.19/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    ensureEvenDistributionOfPartitions: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### New `ensureEvenDistributionOfPartitions` property support\n\nWhen scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to.\n\nConsider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution.\n\nBelow are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default.\n\n- For lag between `1 -> 10` we would be running `1` consumer\n- For lag between `11 -> 20` we would be running `2` consumer\n- For lag between `21 -> 50` we would be running `5` consumers\n- For lag higher than `51` we would be running `10` consumers\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    ensureEvenDistributionOfPartitions: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### New `ensureEvenDistributionOfPartitions` property support\n\nWhen scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to.\n\nConsider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution.\n\nBelow are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default.\n\n- For lag between `1 -> 10` we would be running `1` consumer\n- For lag between `11 -> 20` we would be running `2` consumer\n- For lag between `21 -> 50` we would be running `5` consumers\n- For lag higher than `51` we would be running `10` consumers\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Datastore\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n**TLS authentication:**\n\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - Password for the client certificate private key. (Optional, Required when `key` is encrypted)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```\n\n### Example with TLS (HTTPS with self-signed certificates)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8443\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        unsafeSsl: \"true\"  # Skip certificate validation for self-signed certificates\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```\n\n### Example with mutual TLS (client certificates)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis-tls\n  namespace: kedartemis\ntype: Opaque\ndata:\n  artemis-ca: \"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=\"  # Base64 encoded CA certificate\n  artemis-cert: \"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=\"  # Base64 encoded client certificate\n  artemis-key: \"LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi4uLgo=\"  # Base64 encoded client private key\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis-tls\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: ca\n      name: kedartemis-tls\n      key: artemis-ca\n    - parameter: cert\n      name: kedartemis-tls\n      key: artemis-cert\n    - parameter: key\n      name: kedartemis-tls\n      key: artemis-key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8443\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n      authenticationRef:\n        name: trigger-auth-kedartemis-tls\n```"
  },
  {
    "path": "content/docs/2.19/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Optional: ignoreNullValues\n    ignoreNullValues: \"false\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: Specify metric source AWS Account ID when using CloudWatch cross-account observability\n    awsAccountId: \"\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsAccountId` - Specify metric source AWS Account ID when using CloudWatch cross-account observability\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). Supports all CloudWatch statistics including percentiles (e.g., `p95`, `p50`) and trimmed means (e.g., `tm99`, `tm95`). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response.  If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional)\n\n> Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload.\n\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}, \":filterValue\" : {\"S\" : \"hello world\"}}'\n    # Optional: filterExpression\n    filterExpression: 'filterField = :filterValue'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `filterExpression` - the condition that specifies the filterExpression to be used by the Query action.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n\n> When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n      # Optional. Custom timeout for the HTTP client used in this scaler\n      timeout: \"1000\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n### Links\n\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false\n      # Optional: Require jobs to include specified demands, ignoring any extra ones\n      requireAllDemandsAndIgnoreOthers: false\n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n      # Optional: Whether to only fetch unfinished jobs from the API (default: false)\n      fetchUnfinishedJobsOnly: false\n      # Optional: Property to enable case-insensitive comparison of pipeline job demands (default: false)\n      caseInsensitiveDemandsProcessing: false\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\". Mutually exclusive with `jobsToFetch`.\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API. Mutually exclusive with `parent` and `fetchUnfinishedJobsOnly`. (Default: `250`, Optional)\n- `fetchUnfinishedJobsOnly` - Whether to fetch only unfinished jobs from the Azure Pipeline API. Normally both finished, running and pending jobs are returned by the API. When this parameter is set to `true`, the API call is modified so that only running and pending jobs are returned from the API, which reduces the amount of returned jobs considerably. Mutually exclusive with `jobsToFetch`. (Default: `false`, Optional)\n- `caseInsensitiveDemandsProcessing` - Property to enable case-insensitive comparison of pipeline job demands. When this parameter is set to `true`, the demands check is case-insensitive. (Default: `false`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not use demands in your agent scaler then it scales based on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored).\n  - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n  - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list.\n  - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands:\n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\nHowever, as this an undocumented API, it possesses some unique quirks when calling it with different query parameters. For example, if the `$top` query parameter is given, the format of the returned JSON is changed in such a way that it is no longer possible for the scaler to find the matched agents; making it impossible to use with the `parent` property from the trigger metadata. Therefore making `jobsToFetch` mutually exclusive with `parent` in the trigger metadata.\n\nAdditionally, the `$top` query parameter takes precedence over some other parameters like `completedRequestCount`. If the `$top` query parameter is given, finished jobs are included in the response even if `completedRequestCount=0` is given, although `completedRequestCount=0` would indicate that only pending and running jobs should be returned. Thus, `jobsToFetch` is also mutually exclusive with `fetchUnfinishedJobsOnly` in the trigger metadata.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n\n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    queueLengthStrategy: all|visibleonly\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      # Optional\n      queueLengthStrategy: \"all\" # or visibleonly. Default: all\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/beanstalkd.md",
    "content": "+++\ntitle = \"Beanstalkd\"\navailability = \"v2.16+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on beanstalkd queues\"\ngo_file = \"beanstalkd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue.\n\n```yaml\ntriggers:\n  - type: beanstalkd\n    metadata:\n      server: beanstalkd.internal-namespace:11300\n      includeDelayed: \"false\"\n      tube: \"default\"\n      activationValue: \"10\"\n      value: \"15\"\n      timeout: \"30\"\n```\n\n**Parameter list:**\n\n- `server` - Address of beanstalkd server `<host>:<port>`. If no port is specified then the scaler will default to `11300`.\n- `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted.\n- `tube` - Name of the tube to scale on.\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set.\n- `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional)\n\n### Authentication Parameters\n\nNo authentication should be needed to connect to the beanstalkd server.\n\n### Example\n\n#### Default tube with activation value\n\nHere the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'default'\n        activationValue: \"10\"\n        value: \"20\"\n```\n\n#### User-created tube with minimum replicas\n\nA minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'scaling-tube'\n        value: \"5\"\n        includeDelayed: \"true\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n- `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional).\n- `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional)\n- `key` - Key path for client authentication. Mandatory if tls enabled. (Optional)\n\n### Example with no TLS auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n\n### Example with TLS auth\n\nSince we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. \n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/cassandra\n            name: temp-cassandra-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-cassandra-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/cassandra\n  name: temp-cassandra-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-cassandra-vol\n  emptyDir:\n    medium: Memory\n```\n\nOnce we have the writable mount path set up for the certificates and keys.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n  tls: enable\n  cert: <cert content | base64encoded>\n  key: <key content | base64encoded>\n  ## Optional parameter ca ##\n  ca: <ca cert content | base64encoded>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n  - parameter: tls\n    name: cassandra-secrets\n    key: tls\n  - parameter: cert\n    name: cassandra-secrets\n    key: cert\n  - parameter: key\n    name: cassandra-secrets\n    key: key\n  ## Optional parameter ca ##\n  - parameter: ca\n    name: cassandra-secrets\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be the same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale your deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do it the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.19/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\nThere are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately.\n\n## Using the Datadog Cluster Agent (Experimental)\n\nWith this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches.\n\n### Deploy the Datadog Cluster Agent with enabled external metrics\n\nFirst, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA).\n\nIf you are using Helm to deploy the Cluster Agent, set:\n\n* `clusterAgent.metricsProvider.enabled` to `true`\n* `clusterAgent.metricsProvider.registerAPIService` to `false`\n* `clusterAgent.metricsProvider.useDatadogMetrics` to `true`\n* `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]`\n\nIf you are using the Datadog Operator, add the following options to your `DatadogAgent` object:\n\n```\napiVersion: datadoghq.com/v2alpha1\nkind: DatadogAgent\nmetadata:\n  name: datadog\nspec:\n  features:\n    externalMetricsServer:\n      enabled: true\n      useDatadogMetrics: true\n      registerAPIService: false\n  override:\n    clusterAgent:\n      env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]\n[...]\n```\n\nNOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later.\n\n### Create a DatadogMetric object for each scaling query\n\nTo use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: \"true\"` annotation, to ensure the Cluster Agent retrieves the query value. Example:\n\n```yaml\napiVersion: datadoghq.com/v1alpha1\nkind: DatadogMetric\nmetadata:\n  annotations:\n    external-metrics.datadoghq.com/always-active: \"true\"\n  name: nginx-hits\nspec:\n  query: sum:nginx.net.request_per_s{kube_deployment:nginx}\n```\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"true\"\n    datadogMetricName: \"nginx-hits\"\n    datadogMetricNamespace: \"default\"\n    targetValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    metricUnavailableValue: \"1.5\"\n    timeout: \"10s\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional)\n- `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events.\n- `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events.\n- `targetValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n- `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n> 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as \"no data\" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA.\n\n### Authentication\n\nThe Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below:\n\n**Common to all authentication types**\n- `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional)\n- `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed.\n- `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern.\n- `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional)\n\n**Bearer authentication:**\n- `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: datadog-config\n  namespace: my-project\ndata:\n  datadogNamespace:  # Required: namespace where the Datadog Cluster Agent is deployed\n  datadogMetricsService: # Required: Cluster Agent metrics server service name\n  unsafeSsl: # Optional: set to \"true\" to skip SSL certificate validation\n  authMode:  # Required: authentication mode (bearer)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: datadog-cluster-agent-creds\n  namespace: my-project\nspec:\n   boundServiceAccountToken:\n     - parameter: token\n       serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io\n  configMapTargetRef:\n    - parameter: datadogNamespace\n      name: datadog-config\n      key: datadogNamespace\n    - parameter: unsafeSsl\n      name: datadog-config\n      key: unsafeSsl\n    - parameter: authMode\n      name: datadog-config\n      key: authMode\n    - parameter: datadogMetricsService\n      name: datadog-config\n      key: datadogMetricsService\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx\n  maxReplicaCount: 3\n  minReplicaCount: 1\n  pollingInterval: 60\n  triggers:\n  - type: datadog\n    metadata:\n      useClusterAgentProxy: \"true\"\n      datadogMetricName: \"nginx-hits\"\n      datadogMetricNamespace: \"default\"\n      targetValue: \"2\"\n      type: \"global\"\n      timeout: \"10s\"\n    authenticationRef:\n      name: datadog-cluster-agent-creds\n```\n\n## Using the Datadog REST API\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"false\"\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n    timeout: \"10s\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false)\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n- `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n> 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as \"no data\" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n      # Optional: the HTTP timeout for this trigger\n      timeout: \"10s\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n### Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../reference/scaledobject-spec/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n### Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n#### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n#### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n### Cases of unexpected metrics value in DataDog API response\n\n#### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n#### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.19/scalers/dynatrace.md",
    "content": "+++\ntitle = \"Dynatrace\"\navailability = \"2.15+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Dynatrace metric data points\"\ngo_file = \"dynatrace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points.\n\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      host: https://dummy-instance.live.dynatrace.com/\n      threshold: \"10\"\n      # Optional\n      activationThreshold: \"5\"\n      # Optional\n      metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n      # Optional\n      from: now-2d\n      # Optional\n      query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-2d'\n      # Optional\n      queryTimeoutSeconds: \"10\"\n      # Optional\n      queryPollingWait: \"1s\"\n      # Optional\n      queryPollingTries: \"5\"\n```\n\n**Parameter list:**\n\n- `host` - The Dynatrace instance to query against. (This value can be different when using `metricSelector` than when using `query`)\n- `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). (Optional, Mutually exclusive with `query`)\n\n  Some relevant aspects:\n    - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered\n    - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered\n    - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector\n- `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours, This only applies when `metricSelector` is used; with `query`, the time range must be included within the query)\n- `query` - [DQL](https://docs.dynatrace.com/docs/discover-dynatrace/platform/grail/dynatrace-query-language) query to be executed. (Optional, Mutually exclusive with `metricSelector`)\n\n  Some relevant aspects:\n    - Query must return a single scalar named `r` that KEDA will use as metric, other fields will be ignored.\n    - KEDA will poll 5 times the value with a second between tries, so the query needs to have a result within that window.\n- `queryTimeoutSeconds` - Timeout in seconds passed to fetch data on Dynatrace side (Default: `10`, Optional, Only applies with `query`)\n- `queryPollingWait` - Time between result polling tries (Default: `1s`, Optional, Only applies with `query`)\n- `queryPollingTries` - Total polling tries (Default: `5`, Optional, Only applies with `query`)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float)\n\n> NOTE: Modifying the values of `queryPollingWait` or `queryPollingTries` can increase the response time and the HPA Controller can register timeouts because of this. If your query requires longer times, you should evaluate options like [caching metrics (`useCachedMetrics`)](./../reference/scaledobject-spec.md#triggers) in addition to these parameters.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication for the `host` and `token` parameters.\n\n**Authentication:**\n\n- `host` - The Dynatrace instance to query against (This value can be different when using `metricSelector` than when using `query`)\n- `token` - The API key that will be leveraged to connect to Dynatrace and make requests. For `metricSelector`, token requires the `metrics.read` scope ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). For `query`, token **[has to be a platform token](https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients/platform-tokens)** with enough permissions for the table that you want to use (OIDC client isn't supported).\n\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/\n  token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n        from: 'now-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n\n### DQL Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5hcHBzLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.apps.dynatrace.com/\n  token: ZHQwczE2LlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s16.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n### Troubleshooting & Tips\n\n#### Required Token Permissions for `query` Parameter\n\nWhen using the `query` parameter (DQL-based queries), your platform token must have **both** of the following scopes:\n\n- `storage:metrics:read`\n- `storage:buckets:read`\n\n> **Note:** This is different from `metricSelector`, which only requires `metrics.read`.\n\n#### Testing Your Query with Dynatrace Swagger UI\n\nYou can test your DQL query directly as your token using the Dynatrace Swagger UI before configuring KEDA:\n```\nhttps://<your-environment-id>.apps.dynatrace.com/platform/swagger-ui/index.html?urls.primaryName=Grail+-+DQL+Query#/Query%20Execution/query%3Aexecute\n```\n\nClick the **Authorize** button (top right) and enter your platform token to authenticate. This lets you validate your query and permissions before using them in KEDA.\n\n#### Example: Scaling Based on GCP Pub/Sub via Dynatrace\n\nIf your GCP project is onboarded into Dynatrace, you can scale based on Pub/Sub metrics using a DQL query like this:\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      query: >-\n        timeseries value = max(cloud.gcp.pubsub_googleapis_com.subscription.num_unacked_messages_by_region, scalar:true),\n        filter: gcp.project.id == \"myproject\",\n        from: now()-5m\n        | fields value\n        | append [data record(value = 0.0)]\n        | summarize r = toDouble(max(value))\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html).\n\nThe trigger always requires the following information, but requires either only searchTemplateName **or** only query:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      query: \"my-query\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `query` - The query to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Examples\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        query: |\n          {\n            \"size\": 0,\n            \"query\": {\n              \"bool\": {\n                \"must\": [\n                  {\n                    \"term\": {\n                      \"service.name\": \"my-application\" }\n                  },\n                  {\n                    \"term\": {\n                      \"service.environment\": \"production\" }\n                  },\n                  {\n                    \"range\": {\n                      \"@timestamp\": {\n                        \"gte\": \"now-2m\",\n                        \"lte\": \"now-1m\"\n                      }\n                    }\n                  }\n                ]\n              }\n            },\n            \"aggs\": {\n              \"transaction_count\": {\n                \"cardinality\": {\n                  \"field\": \"transaction.id\" }\n              }\n            }\n          }\n        valueLocation: \"aggregations.transaction_count.value\"\n        targetValue: \"1000\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n        usernameFromEnv: <admin-user>  # Optional\n        passwordFromEnv: <admin-password> # Optional\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Password based authentication:**\n\n- `username` - Username for authentication. (Optional)\n- `password` - Password for authentication. (Optional)\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on Password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  etcd-username: <your username>\n  etcd-password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-etcd-secrets\n      key: etcd-username\n    - parameter: password\n      name: keda-etcd-secrets\n      key: etcd-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    enableTLS: false\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/forgejo.md",
    "content": "+++\ntitle = \"Forgejo\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on pending jobs on Forgejo repository.\"\ngo_file = \"forgejo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `forgejo-runner` trigger for Forgejo Actions. It scales based on the amount of jobs pending in given runner labels.\n\n```yaml\ntriggers:\n  - type: forgejo-runner\n    metadata:\n      # Required: the name of the registered runner \n      name: \"forgejo-runner-ubuntu\"\n      # Required: the url of the forgejo instance \n      address: \"http://localhost:3000\"\n      # Optional: Scope of the jobs to check, global is the default one and will get all the jobs in the instance with the defined labels\n      global: \"true\" \n      # Optional: User to set as a scope, global should be false, if no repo is set will get all the pending jobs for the user\n      owner: \"cobak\"\n      # Optional: Repository level scope\n      repo: \"my-repo\"\n      # Required: Will get the jobs with match with this labels\n      labels: \"ubuntu-latest\"\n```\n\n**Parameter list:**\n\n- `name` - Name of the registered runner.\n- `address` - Url of the forgejo instance.\n- `global` - Scope of the jobs to check. (Values: `true`, `false`, Default: `true`, Optional, Mutually exclusive with `owner` and `repo`)\n- `owner` - User to set as a scope. (Optional, Mutually exclusive with `global` and `repo`)\n- `repo` - User to set as a scope. (Optional, Mutually exclusive with `global` and `owner`)\n- `labels` - Labels to match the job with.\n\n\n### Authentication Parameters\n\n- `token` - Required token to connect to forgejo instance.\n\n### Options on how to set the scope (global, user, repo)\n\n1. If you set owner and repo KEDA forgejo scaler will retrieve jobs from that repository:\n   ```\n   owner: \"username\"\n   repo: \"my_repo\"\n   ```\n2. If you set the organization will retrieve the organization jobs:\n   ```\n   org: \"my_org\"\n   ```\n3. If you set global: true will retrieve all the jobs from the instance\n   ```\n   global: \"true\"\n   ```\n4. And if you don't set any of this optional fields will retrieve the jobs from the user who creates the token \n\n## Configuration \n\n### Registering runners and binding config with autoscalers\n\nTo match job endpoints with job execution, we need to pre-register a runner, save the generated JSON file as a ConfigMap, and share it with the autoscaler. review the different ways to register a runner [here](https://forgejo.org/docs/latest/admin/runner-installation/#standard-registration), select the desired scope (user, repository or global) and create the corresponding JSON file. \n\nAutoscaler definition and runner registration should match to work as expected.\n\nCreate a .runner file and a registration file with this commands, and set the output in a configmap.\n\n```shell\ndocker run -v /var/run/docker.sock:/var/run/docker.sock  -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner register --no-interactive --token xxxx --name runner --instance http://localhost:3000/ --labels ubuntu-20:docker://node:20-bookworm,docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\ndocker run -v /var/run/docker.sock:/var/run/docker.sock  -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner generate-config > registration.yaml \n```\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: runner-config\n  namespace: runners\ndata:\n  .runner: |\n    {\n        \"WARNING\": \"This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.\",\n        \"id\": 3,\n        \"uuid\": \"be6b5260-e73f-4e21-af84-8e205dbaaacd\",\n        \"name\": \"runner\",\n        \"token\": \"<global-runner-token>\",\n        \"address\": \"http://localhost:3000/\",\n        \"labels\": [\n            \"ubuntu-20:docker://node:20-bookworm\",\n            \"docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\"\n        ]\n      }\n\n---\n\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: runner-registration\n  namespace: runners\ndata:\n  registration.yaml: |\n    log:\n      # The level of logging, can be trace, debug, info, warn, error, fatal\n      level: info\n      # The level of logging for jobs, can be trace, debug, info, earn, error, fatal\n      job_level: info\n\n    runner:\n      # Where to store the registration result.\n      file: /data/.runner\n      # Execute how many tasks concurrently at the same time.\n      capacity: 1\n      # Extra environment variables to run jobs.\n      envs:\n        DOCKER_HOST: tcp://localhost:2376\n        DOCKER_TLS_VERIFY: 1\n        DOCKER_CERT_PATH: /certs/client\n      # Extra environment variables to run jobs from a file.\n      # It will be ignored if it's empty or the file doesn't exist.\n      env_file: .env\n      # The timeout for a job to be finished.\n      # Please note that the Forgejo instance also has a timeout (3h by default) for the job.\n      # So the job could be stopped by the Forgejo instance if it's timeout is shorter than this.\n      timeout: 3h\n      # The timeout for the runner to wait for running jobs to finish when\n      # shutting down because a TERM or INT signal has been received.  Any\n      # running jobs that haven't finished after this timeout will be\n      # cancelled.\n      # If unset or zero the jobs will be cancelled immediately.\n      shutdown_timeout: 3h\n      # Whether skip verifying the TLS certificate of the instance.\n      insecure: false\n      # The timeout for fetching the job from the Forgejo instance.\n      fetch_timeout: 5s\n      # The interval for fetching the job from the Forgejo instance.\n      fetch_interval: 2s\n      # The interval for reporting the job status and logs to the Forgejo instance.\n      report_interval: 1s\n      # The labels of a runner are used to determine which jobs the runner can run, and how to run them.\n      # Like: [\"macos-arm64:host\", \"ubuntu-latest:docker://node:20-bookworm\", \"ubuntu-22.04:docker://node:20-bookworm\"]\n      # If it's empty when registering, it will ask for inputting labels.\n      # If it's empty when executing the `daemon`, it will use labels in the `.runner` file.\n      labels:\n        - ubuntu-20:docker://node:20-bookworm\n        - docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\n\n    cache:\n      # Enable cache server to use actions/cache.\n      enabled: true\n      # The directory to store the cache data.\n      # If it's empty, the cache data will be stored in $HOME/.cache/actcache.\n      dir: \"\"\n      # The host of the cache server.\n      # It's not for the address to listen, but the address to connect from job containers.\n      # So 0.0.0.0 is a bad choice, leave it empty to detect automatically.\n      host: \"\"\n      # The port of the cache server.\n      # 0 means to use a random available port.\n      port: 0\n      # The port of the cache proxy.\n      # 0 means to use a random available port.\n      proxy_port: 0\n      # The external cache server URL. Valid only when enable is true.\n      # If it's specified, it will be used to set the ACTIONS_CACHE_URL environment variable. The URL should generally end with \"/\".\n      # Otherwise it will be set to the the URL of the internal cache server.\n      external_server: \"\"\n      # The shared cache secret. When communicating with a cache server, the runner uses this secret to verify the authenticity of the cache requests.\n      # When using an external cache server it is required to set the same secret for the runner and the cache server.\n      secret: \"\"\n      # Overrides the ACTIONS_CACHE_URL passed to workflow containers. This should only be used if the runner host is not reachable from the\n      # workflow containers, and requires further setup.\n      actions_cache_url_override: \"\"\n\n    container:\n      # Specifies the network to which the container will connect.\n      # Could be host, bridge or the name of a custom network.\n      # If it's empty, create a network automatically.\n      network: host\n      # Whether to create networks with IPv6 enabled. Requires the Docker daemon to be set up accordingly.\n      # Only takes effect if \"network\" is set to \"\".\n      enable_ipv6: false\n      # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker).\n      privileged: false\n      # And other options to be used when the container is started (eg, --add-host=my.forgejo.url:host-gateway).\n      options: -v /certs/client:/certs/client\n      # The parent directory of a job's working directory.\n      # If it's empty, /workspace will be used.\n      workdir_parent:\n      # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob\n      # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted.\n      # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to:\n      # valid_volumes:\n      #   - data\n      #   - /src/*.json\n      # If you want to allow any volume, please use the following configuration:\n      # valid_volumes:\n      #   - '**'\n      valid_volumes:\n        - /certs/client\n      # overrides the docker client host with the specified one.\n      # If \"-\" or \"\", an available docker host will automatically be found.\n      # If \"automount\", an available docker host will automatically be found and mounted in the job container (e.g. /var/run/docker.sock).\n      # Otherwise the specified docker host will be used and an error will be returned if it doesn't work.\n      docker_host: \"-\"\n      # Pull docker image(s) even if already present\n      force_pull: false\n      # Rebuild local docker image(s) even if already present\n      force_rebuild: false\n\n    host:\n      # The parent directory of a job's working directory.\n      # If it's empty, $HOME/.cache/act/ will be used.\n      workdir_parent:\n\n```\n\n### Create a token on forgejo\n\nThe autoscaler will continuously fetch new waiting jobs from Forgejo, so it requires a properly configured token with the appropriate permissions. Navigate to **Forgejo > User settings > Applications > Access Tokens** and generate a new token. This token will be used by the autoscaler\n\n### Configuring KEDA Autoscaler\n\nCreate a new custom resource with the required parameters and custom fields based on the scope chosen during runner registration. For example, set `global=\"true\"` for global runners or specify `repo=xxx` and `owner=xxx` for repository level runners.\n\nChoose the runner image you want to use (>6.1 of forgejo runner releases) or a custom one with `--one-job` command. \n\nApply the new custom resource to your cluster.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: forgejo-runner-secret\n  namespace: runners\ndata:\n  token: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: forgejo-runner-creds\n  namespace: runners\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: forgejo-runner-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  labels:\n    app: forgejo-runner\n  name: upload-platform-forgejo-runner\n  namespace: runners\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: forgejo-runner\n      spec:\n        volumes:\n          - name: runner-data\n            emptyDir: {}\n          - name: runner-config\n            configMap:\n              name: upload-platform-runner-config\n          - name: runner-registration\n            configMap:\n              name: upload-platform-runner-registration\n          - name: docker-certs\n            emptyDir: {}\n        restartPolicy: Never\n        shareProcessNamespace: true\n        containers:\n          - name: runner\n            image: code.forgejo.org/forgejo/runner:6.3.1\n            command:\n              - sh\n              - -c\n              - |\n                while ! nc -z localhost 2376 </dev/null; do \n                  echo 'waiting for docker daemon...'\n                  sleep 5\n                done\n\n                cp /config/.runner /data/.runner\n\n                exec forgejo-runner -c /registration/registration.yaml one-job\n            securityContext:\n              privileged: true\n              runAsUser: 0\n            env:\n              - name: DOCKER_HOST\n                value: tcp://localhost:2376\n              - name: DOCKER_CERT_PATH\n                value: /certs/client\n              - name: DOCKER_TLS_VERIFY\n                value: \"1\"\n            volumeMounts:\n              - name: docker-certs\n                mountPath: /certs\n              - name: runner-data\n                mountPath: /data\n              - name: runner-registration\n                mountPath: /registration\n                readOnly: false\n              - name: runner-config\n                mountPath: /config\n                readOnly: false\n          - name: daemon\n            image: docker:27.4.1-dind\n            command:\n              - sh\n              - -c\n              - |\n                dockerd-entrypoint.sh 2>&1 &\n\n                while kill -0 7 2>/dev/null\n                  do sleep 10 \n                  echo \"watching main job execution\"\n                done;\n\n                sleep 10\n\n                echo \"main container exited, stopping dind\"\n                exit 0\n            env:\n              - name: DOCKER_TLS_CERTDIR\n                value: /certs\n              - name: DOCKER_HOST\n                value: tcp://0.0.0.0:2376\n            securityContext:\n              privileged: true\n              runAsUser: 0\n            volumeMounts:\n              - name: docker-certs\n                mountPath: /certs\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n    - type: forgejo-runner\n      metadata:\n        name: \"runner\"\n        address: \"http://localhost:3000/\"\n        global: \"true\"\n        labels: \"ubuntu-20,docker\"\n      authenticationRef:\n        name: forgejo-runner-creds\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    filterDuration: '1' # Optional - Default is 2\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # The 'subscriptionSize' setting is DEPRECATED and will be removed in v2.20 - Use 'mode' and 'value' instead\" \n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    valueIfNull: '0.0' # Optional - Default is \"\"\n    activationValue: \"10.5\" # Optional - Default is 0\n    timeHorizon: \"1m\" # Optional - Default is 2m and with aggregation 5m\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`)\n\n- `valueIfNull` - Value returned if request returns no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    filterDuration: '1' # Optional - Default is 2\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\", defaults to \"false\" (scale on default runner labels)\n      noDefaultLabels: \"{noDefaultLabels}\"\n      # Optional: When enabled unlabeled jobs will not match unlabeled runners. Can be either \"true\" or \"false\", defaults to \"false\"\n      matchUnlabeledJobsWithUnlabeledRunners: \"{matchUnlabeledJobsWithUnlabeledRunners}\"\n      # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either \"true\" or \"false\", defaults to \"false\"\n      enableEtags: \"{enableEtags}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabels` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"). (Values: `true`,`false`, Default: \"false\", Optional)\n- `matchUnlabeledJobsWithUnlabeledRunners` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: \"false\", Optional)\n- `enableEtags` -  Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabelsFromEnv` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\". (Optional)\n- `matchUnlabeledJobsWithUnlabeledRunnersFromEnv` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows,\nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations:\n\n- Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories.\n- Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`.\n\nNote: This does not apply to a hosted appliance as there are no rate limits.\n\nAdditional Note: The GitHub App authentication method has a rate limit of 15000 rather than 5000 per hour.\n\n**Fine-Tuning**\n\nThe current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters.\n\nFor example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly.\n\n*Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).*\n\nAt the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) (**The 'minMetricValue' setting is DEPRECATED and will be removed in v2.20 - Use 'activationTargetMetricValue' instead**)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueName: <queue-name> # REQUIRED - Your queue name\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n    unsafeSsl: \"false\" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ).\n- `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\nExample with Basic Auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n        usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n\nExample with Basic Auth and TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n  cert: <your tls.crt>\n  key: <your tls.key>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n    - parameter: cert\n      name: keda-ibmmq-secret\n      key: cert\n    - parameter: key\n      name: keda-ibmmq-secret\n      key: key\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org # Required for InfluxDB v2.x, optional for InfluxDB v3.x\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      metricKey: 'mymetric' # Required for Influx v3. Ignored for v2. See details in \"Parameter List\" section\n      queryType: 'InfluxQL' # Required for Influx v3. Ignored for v2. See details in \"Parameter List\" section\n      influxVersion: '2' # Optional: Defaults to 2.\n      database: 'some-influx-db' # Required for Influx v3\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc (Optional, Required if `influxVersion: '2'`).\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `influxVersion` - Specifies the version of InfluxDB being used. (Values: `2`, `3`, Default: `2`, Optional)\n- `database` - The name of the InfluxDB database to query. Required for InfluxDB v3.x. (Optional for InfluxDB v2.x)\n- `metricKey` - The name of the metric to be used for scaling decisions. This is required for InfluxDB v3.x and ignored for InfluxDB v2.x. It is used to identify the metric in the query results. For a `query` of `SELECT mean(\"mymetric\") AS \"metric_name\" FROM...` use `metricKey: 'metric_name'`. (Optional, Required if `influxVersion: '3'`)\n- `queryType` - Specifies the type of query being used. For InfluxDB v3.x, this can be either `InfluxQL` or `FlightSQL`. For InfluxDB v2.x, this parameter is ignored. (Values: `InfluxQL`, `FlightSQL`, Default: `InfluxQL`, Optional)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example (InfluxDB v2)\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` (v2) scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n\n### Example (InfluxDB v3)\n\nBelow is a similar example for Influx v3 using an `InfluxQL` query.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        database: 'my-metrics-db'\n        influxVersion: '3'\n        queryType: 'InfluxQL'\n        metricKey: 'mean'\n        thresholdValue: '2'\n        activationThresholdValue: '10'\n        query: |\n          SELECT mean(\"water_level\") FROM \"h2o_feet\"\n          GROUP BY time(5m)\n          ORDER BY time DESC LIMIT 1;\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/kubernetes-resource.md",
    "content": "+++\ntitle = \"Kubernetes Resource\"\navailability = \"v2.19+\"\nmaintainer = \"Community\"\ncategory = \"Kubernetes\"\ndescription = \"Scale applications based on values in Kubernetes ConfigMaps or Secrets\"\ngo_file = \"kubernetes_resource_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `kubernetes-resource` trigger that scales based on a value found in a Kubernetes ConfigMap or Secret.\n\nThis scaler allows users to scale workloads by extracting values from Kubernetes resources, supporting number, JSON, and YAML formats.\n\nHere is an example of trigger configuration using kubernetes-resource scaler:\n\n```yaml\ntriggers:\n- type: kubernetes-resource\n  metadata:\n    resourceKind: \"Secret\"\n    resourceName: \"my-secret\"\n    key: \"data\"\n    format: \"json\"\n    valueLocation: \"count\"\n    valueType: \"float64\"\n    targetValue: \"10\"\n    activationTargetValue: \"5\"\n```\n\n**Parameter list:**\n\n- `resourceKind` - Type of Kubernetes resource to read from. Supported values: `ConfigMap`, `Secret` (Required)\n- `resourceName` - Name of the resource to read. (Required)\n- `key` - Key in the ConfigMap's `data` field or Secret's `data` field to read from. The value at this key is retrieved as a string. (Required)\n- `format` - Format of the string value retrieved from `key`. Supported values: `number`, `json`, `yaml`. (Default: `number`, Optional)\n  - `number` - The string value is parsed directly as a number\n  - `json` - The string value is a JSON document, and `valueLocation` extracts a field from it\n  - `yaml` - The string value is a YAML document, and `valueLocation` extracts a field from it\n- `valueLocation` - Path to extract the metric value from the JSON or YAML content retrieved from `key`. Required for `json` and `yaml` formats. Not used for `number` format. For `json`, use [GJSON path notation](https://github.com/tidwall/gjson#path-syntax). For `yaml`, use dot-separated path (e.g., `foo.bar.count`). (Optional)\n- `valueType` - Type of value to extract. Supported values: `float64`, `int64`, `quantity`. (Default: `float64`, Optional)\n  - `float64` - Floating point number. For JSON format, accepts both numbers and quantity strings.\n  - `int64` - Integer number. For JSON format, only accepts integer numbers (decimal values are truncated). For `number` format, the string must be parseable as an integer.\n  - `quantity` - Kubernetes quantity (e.g., \"100m\", \"1Gi\"). For JSON/YAML formats, parses string values as quantities. For JSON format, also accepts raw numbers.\n- `targetValue` - Target value to scale on. When the extracted value is equal or higher, KEDA will scale out. (Required)\n- `activationTargetValue` - Value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNo authentication parameters are required. The scaler uses the permissions of the KEDA operator to access resources in the same namespace.\n\n### Example\n\nHere is a full example of scaled object definition using Kubernetes Resource trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: k8s-resource-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 10\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"my-configmap\"\n        key: \"metrics\"\n        format: \"yaml\"\n        valueLocation: \"count\"\n        valueType: \"int64\"\n        targetValue: \"10\"\n```\n\nAssuming the ConfigMap contains:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: my-configmap\n  namespace: keda\ndata:\n  metrics: |\n    count: 12\n    other: value\n```\n\nThe scaler will extract the value at `count` from the YAML data in the `metrics` key and use it for scaling decisions.\n\n> 💡 **NOTE:** \n> - The `valueType` parameter controls how values are parsed. For `int64`, decimal values in JSON are truncated to integers.\n> - For `json` format, use GJSON path syntax. For `yaml` format, use dot-separated path. For `number` format, the value at the key is used directly.\n> - For YAML format, the `valueType` determines how the extracted value is converted, regardless of whether the value is a string or a native YAML number. For example, if `valueType` is set to `int64`, the value will be converted to an integer; if set to `quantity`, it will be parsed as a Kubernetes quantity. By default, numeric YAML values are converted to float64 unless a different `valueType` is specified.\n\n### Additional Examples\n\n#### Example 1: Number Format (Direct Value)\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: task-count\n  namespace: keda\ndata:\n  count: \"42\"\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: task-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: worker-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"task-count\"\n        key: \"count\"\n        format: \"number\"\n        valueType: \"float64\"\n        targetValue: \"50\"\n        activationTargetValue: \"10\"\n```\n\nIn this example, the value `42` from the `count` key is used directly.\n\n#### Example 2: JSON Format\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: metrics-data\n  namespace: keda\nstringData:\n  metrics: |\n    {\n      \"queue\": {\n        \"pending\": 25,\n        \"processing\": 5\n      }\n    }\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: queue-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: processor-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"Secret\"\n        resourceName: \"metrics-data\"\n        key: \"metrics\"\n        format: \"json\"\n        valueLocation: \"queue.pending\"\n        valueType: \"int64\"\n        targetValue: \"20\"\n```\n\nIn this example, the GJSON path `queue.pending` extracts the value `25` from the JSON data.\n\n#### Example 3: YAML Format with Nested Path\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: app-metrics\n  namespace: keda\ndata:\n  stats: |\n    application:\n      workers:\n        active: 15\n        idle: 3\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: worker-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: worker-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"app-metrics\"\n        key: \"stats\"\n        format: \"yaml\"\n        valueLocation: \"application.workers.active\"\n        valueType: \"int64\"\n        targetValue: \"10\"\n```\n\nIn this example, the dot-separated path `application.workers.active` extracts the value `15` from the YAML data.\n\n#### Example 4: Quantity Type\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: resource-limits\n  namespace: keda\ndata:\n  memory: |\n    {\n      \"available\": \"2Gi\",\n      \"used\": \"512Mi\"\n    }\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: worker-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"resource-limits\"\n        key: \"memory\"\n        format: \"json\"\n        valueLocation: \"used\"\n        valueType: \"quantity\"\n        targetValue: \"1024000000\"  # 1Gi in bytes\n```\n\nIn this example, the quantity string `\"512Mi\"` is parsed and converted to its float64 representation for scaling decisions.\n\n> ⚠️ **Important:** When using `valueType: \"int64\"` with JSON format, decimal values will be truncated. For example, if the JSON contains `{\"count\": 25.7}`, it will be treated as `25`.\n\n### Supported Formats and Value Extraction\n\nThe scaler works in two steps:\n\n1. **Retrieve the raw string**: Read the value from `ConfigMap.data[key]` or `Secret.data[key]`\n2. **Extract the metric**: Parse the raw string based on the `format`:\n   - **number**: The raw string is parsed directly as a number. No `valueLocation` is needed.\n     - Example: If `key=\"count\"` and `ConfigMap.data.count = \"42\"`, the metric value is `42`\n   - **json**: The raw string is parsed as JSON, then `valueLocation` (using GJSON syntax) extracts the metric value.\n     - Example: If `key=\"metrics\"` and `ConfigMap.data.metrics = '{\"tasks\": 10}'`, with `valueLocation=\"tasks\"`, the metric value is `10`\n   - **yaml**: The raw string is parsed as YAML, then `valueLocation` (using dot-separated path) extracts the metric value.\n     - Example: If `key=\"stats\"` and `ConfigMap.data.stats = 'count: 15'`, with `valueLocation=\"count\"`, the metric value is `15`\n\n### Limitations\n\n- Only resources in the same namespace as the ScaledObject are supported.\n- No cross-namespace access.\n- Only ConfigMaps and Secrets are supported.\n- The scaler uses the KEDA operator's service account permissions to access resources.\n\n### See Also\n\n- [KEDA Concepts: Activating and Scaling Thresholds](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds)\n- [GJSON Path Syntax](https://github.com/tidwall/gjson#path-syntax)\n"
  },
  {
    "path": "content/docs/2.19/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n  - type: metrics-api\n    metadata:\n      targetValue: \"8.8\"\n      format: \"json\"\n      activationTargetValue: \"3.8\"\n      url: \"http://api:3232/api/v1/stats\"\n      valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n  If `aggregateFromKubeServiceEndpoints` is set to `true`, the URL must use Kubernetes DNS format:\n  `http://<service>.<namespace>[.svc.cluster.local]:<pod-port>/path`, where the port must be the pod port\n  targeted by the service, not the service port.\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `aggregateFromKubeServiceEndpoints` - Whether to treat `url` as a kubernetes service and scrape/aggregate metrics for all of this service's endpoints. (Values: `true`, `false`, Default: `false`, Optional)\n- `aggregationType` - How to aggregate metrics when `aggregateFromKubeServiceEndpoints` is set to `true`, ignored otherwise. (Values: `average`, `sum`, `max`, `min`, Default: `average`, Optional)\n\n### Note on aggregation from kubernetes service\n\nwhen setting `aggregateFromKubeServiceEndpoints: true` in metadata, Metrics API Scaler is able to compute basic `average`, `sum`, `min` or `max` aggregation asked by `aggregationType` metadata from all endpoint targets of a kubernetes API service, which is a handy feature in an environment where one didn't set up a metric aggregator/scraping stack (i.e prometheus), or simply doesn't want to use their monitoring stack to fetch and serve metrics from customers workload in their own kubernetes clusters, and leave the metrics API's responsibility up to the customer\n\nThis specific behavior comes from the fact that querying a kubernetes service directly (= setting `aggregateFromKubeServiceEndpoints: false`) would return the metric from a single replica randomly, depending on the load-balancing configuration for the service, and lead to inconsistent HPA average metric computation and eventually to scaling issues as metrics from all replicas won't be taken into account\n\nHere is an example of a ScaledObject using `aggregateFromKubeServiceEndpoints`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"8.8\"\n        url: \"http://my-service.my-namespace.svc.cluster.local:8080/api/v1/stats\"\n        valueLocation: \"components.worker.tasks\"\n        aggregateFromKubeServiceEndpoints: \"true\"\n        aggregationType: \"sum\"\n```\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below. Multiple authentication methods can be used simultaneously by providing a comma-separated list in the `authMode` parameter, for example `authMode: \"apiKey,tls\"` enables both API key and TLS certificate authentication in a single request.\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur. This value can be a float.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\nAutoscaling trigger based on transaction duration average metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n\nAutoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO\"\n        noDataError: \"true\"\n        threshold: '300'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/nsq.md",
    "content": "+++\ntitle = \"NSQ\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NSQ topic/channel depth.\"\ngo_file = \"nsq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. \n\n```yaml\ntriggers:\n- type: nsq\n  metadata:\n    nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n    topic: \"example_topic\"\n    channel: \"example_channel\"\n    depthThreshold: \"10\"\n    activationDepthThreshold: \"0\"\n    useHttps: \"false\"\n    unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `<hostname>:<port>`.\n- `topic` - Name of the NSQ datastream that the `channel` relates to.\n- `channel` - Name of the channel used to calculate depth.\n- `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional)\n- `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional)\n- `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n> **Notice:**\n> - Since [\"channels are created on first use by subscribing to the named channel\"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0.\n> - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nsq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nsq-consumer-deployment\n  triggers:\n  - type: nsq\n    metadata:\n      nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n      topic: \"example_topic\"\n      channel: \"example_channel\"\n      depthThreshold: \"10\"\n      activationDepthThreshold: \"0\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.19/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for three connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret).\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nIt is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity.  \nMore details and an example are provided down below.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return a numeric value (integers and floats are both supported).\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n\n> Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n\n**Azure Access Token authentication:**\n\n#### Prerequisites:\n- The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity).\n- The UAMI should be granted access to the table mentioned in the query performed by KEDA.  \nThis can be achieved by:\n  - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role.\n  - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like  \n  `GRANT ALL ON <TABLE_REF> TO \"<AZURE_UAMI_NAME>\";`.\n\nNext, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process.\n  - `host` - FQDN of the Azure Postgres Flexible Server.\n  - `userName` - Name of the UAMI Azure identity (`<AZURE_UAMI_NAME>`).\n  - `port` - Postgresql port (the default value is `\"5432\"`, please have a look at the `Remarks` down below).\n  - `dbName` - Postgresql Database name.\n  - `sslmode` - SSL policy for communicating with database (the value should be `require`).\n\n\n#### Remarks\n\n- While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port.\n\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-pg-flex-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      authenticationRef:\n        name: azure-pg-flex-auth\n      metadata:\n        host: <AZURE_POSTGRES_FLEX_SERVER_FQDN>\n        port: \"5432\"\n        userName: <UAMI_NAME>\n        dbName: <DB_NAME>\n        sslmode: require\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```"
  },
  {
    "path": "content/docs/2.19/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n    timeout: \"1000\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n- `timeout` - Timeout **for this specific trigger**. Can be given as a number (in milliseconds) or in a human-readable format like \"30s\". This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.19/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://<host>:<port>/<vhost> # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either `amqp`, `http`, or `auto` for auto-detection based on the `host` value. Default value is `auto`.\n    mode: QueueLength # Supported modes are `QueueLength`, `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` or `ExpectedQueueConsumptionTime`\n    value: \"100.50\" # A value defining the threshold (per instance) that, when exceeded, triggers the scaling.\n    activationValue: \"10.5\" # Optional. Activation threshold, which by default is 0.\n    queueName: testqueue # Name of the queue.\n    vhostName: / # Optional. If not specified, use the VHost in the `host` connection string. Required for Azure AD Workload Identity authorization (see below).\n    # You can use existing environment variables to read configuration from. For details see \"Parameters list\" section.\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter.\n    usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of `TriggerAuthentication`.\n    passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of `TriggerAuthentication`.\n    unsafeSsl: true # Optional. Whether to allow unsafe SSL connections.\n    timeout: 1000 # Optional. Custom timeout for the HTTP client used in this scaler.\n```\n\n**Parameters list:**\n\n- `host` - RabbitMQ host address in the format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example, the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain `vhost`, then the trailing slash is required, e.g. `http://guest:password@localhost:5672/`. When using a username with password consider using `hostFromEnv` or a `TriggerAuthentication`.\n- `queueName` - Name of the queue to read required information and stats from.\n- `mode` - Trigger mode. See [Choosing the right trigger mode](#choosing-the-right-trigger-mode) for additional details. Can be one of:\n  - `QueueLength` - trigger on number of messages in the queue\n  - `MessageRate` - trigger on the publishing rate reported by the queue\n  - `DeliverGetRate` - trigger on the rate of delivered messages (to consumers or in response to `basic.get`, both acknowledged and not) reported by the queue\n  - `PublishedToDeliveredRatio` - trigger on the value of ratio of `MessageRate` to `DeliverGetRate`\n  - `ExpectedQueueConsumptionTime` - trigger on the value of expected time (in seconds) of consumption of all messages currently available in the queue (utilizes `QueueLength`, `MessageRate` and `DeliverGetRate` metrics).\n- `value` - A value defining the threshold (per instance) that, when exceeded, triggers the scaling (can be a floating-point number depending on the trigger mode).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) (default: `0`; optional; can be a floating-point number).\n- `protocol` - Protocol to be used for communication (values: `auto`, `http`, `amqp`; default: `auto`; optional).\n- `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (it's optional by default but **it is required** if Azure AD Workload Identity authorization is used).\n- `queueLength` - **DEPRECATED: please use `mode: QueueLength` and `value: ##` instead**. Defines a threshold value for the queue length passed to the scaler. For example: if one pod can handle 10 messages, set the queue length target to `10`. If the actual number of messages in the queue is 30, the scaler will scale up to 3 pods. Default is set to `20` unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of using full name (values: `true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol).\n- `pageSize` - This parameter allows setting the page size (default: `100`; optional; only applies when `useRegex` is set to `true`).\n- `operation` - Operation that will be applied to compute the number of messages in case when `useRegex` is enabled (values: `sum`, `max`, `avg`; defaults: `sum`; optional).\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT` (optional; only applies to hosts that use the `http` protocol).\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (ready messages only; values:`true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol).\n- `unsafeSsl` - Whether to allow unsafe SSL connections (values: `true`, `false`, default: `false`).\n\nSome parameters can be provided using environment variables instead of setting them directly in metadata:\n- `hostFromEnv` - reads the host and port of the RabbitMQ server from selected environment variable (in similar format as `host` parameter)\n- `usernameFromEnv` - reads the username from selected environment variable, which is used to connect to the broker’s management endpoint\n- `passwordFromEnv` - reads the password from selected environment variable, which is used to connect to the broker’s management endpoint.\n\n> 💡 **Notes:** \n> - `host`/`hostFromEnv` has an optional VHost name after the host slash which will be used to scope API request\n> - when using `host`/`hostFromEnv` or `TriggerAuthentication`, the supplied password cannot contain special characters\n> - trigger modes `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` require `http` protocol.\n> - setting `useRegex` to `true` also requires `protocol` to be set to `http`.\n\n> ⚠ **Important:**\n> - If you have unacknowledged messages and you want to have these counted for the scaling to happen, make sure to utilize the `http` protocol (only REST API interface allows for these to be counted).\n> - If scaling against many is desired, then the `ScaledObject` should have all desired triggers defined. HPA will scale based on the largest result considering each of triggers independently.\n\n### Choosing the right trigger mode\n\nBelow you can find available trigger modes with most common usage scenarios:\n- `QueueLength` - Mainly used to scale messages consuming services, where it is desired to keep number of messages in the queue at selected, nominal level.\n- `MessageRate` - Mainly used to scale messages consuming services, where it is desired to keep the consumption rate up to messages publication rate (or higher).\n- `DeliverGetRate` - This specific trigger is actually a byproduct of the resulting implementation of `PublishedToDeliveredRatio` trigger (it was implemented to be used within `scalingModifiers` as a part of composite metric), yet it still has its use in some scenarios. E.g. assuming there's a well known consumer service performance ballpark, `DeliverGetRate` trigger can be utilized to scale out messages publishing service in order to increase publication rate. In this particular example however, upper publication rate limit must be properly guarded by another trigger or by [`maxReplicaCount`](./../reference/scaledobject-spec/#maxreplicacount) so as not to scale infinitely (which could result in overloading the broker, or consumers, or both).\n- `PublishedToDeliveredRatio` - This trigger is used mainly to control consumer pods scaling to keep publishing and consuming rates at stable level. Assuming that this is the case, the principle of operation is this:\n  - if publishing rate is greater than `value` (usually it is a value slightly above `1`), trigger will initiate scale-out process to launch more consumer pods\n  - if publishing rate is equal to consumption rate (value `1`) then it is the indicator that capacity of consumers is sufficient for handling ongoing messages processing and no additional pods need to be added to the pool\n  - if ratio is below `1`, HPA can gracefully take down some consumers but keep messages processing rate at stable level.\n- `ExpectedQueueConsumptionTime` - A trigger primarily used to scale consumer pods, which uses estimate value of pending time to deliver all available messages in the queue to the consumers. If it becomes active in this particular scenario, returned metric indicates growing number of messages due either increased publishing rate or degraded performance of currently active number of consumers. It relies on proper setting of `pollingInterval` (see below for details).\n\n> ⚠ **Important:**\n> - With `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` it is advised to set `metricType: Value` in the trigger configuration to rely on absolute metric value and not the average value across all scaled pods. For reference see [`triggers.metricType`](./../reference/scaledobject-spec/#triggers) and [`scalingModifiers.metricType`](./../reference/scaledobject-spec/#scalingmodifiersmetrictype).\n> - When using `PublishedToDeliveredRatio`, having stable publication to consumption rate may not indicate that consumers pool is of the right size to do the job, since the messages consuming capabilities can change over time, which may result in much higher number of consumers than actually needed. It is then recommended to periodically re-evaluate consumers pool size using different, probably external metric (e.g. consumers count number, size of prefetch buffer, consumer performance, etc.).\n> - Since `ExpectedQueueConsumptionTime` trigger mode is based on the expected time (in seconds) for the selected queue to be emptied of all messages (including estimated count of published messages during sample probing), it must be served with `pollingInterval` set to 1 second. However, in case where such frequent polling may be expensive, it is recommended to use `ExpectedQueueConsumptionTime` in `scalingModifiers` using additional triggers values in formula like so: `(ExpectedQueueConsumptionTime - (QueueLength / DeliverGetRate)) * pollingInterval + (QueueLength / DeliverGetRate)`.\n\n### Authentication Parameters\n\n`TriggerAuthentication` CRD is used to connect and authenticate to RabbitMQ:\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n  > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n- `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (optional, but **required** if Azure AD Workload Identity authorization is used).\n\n#### Username and Password based authentication\n\nThis allows sensitive credentials to be stored and managed separately from the connection string:\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** If username or password are set in `TriggerAuthentication` or environment variables, they will override any credentials provided in the `host` parameter.\n\n#### TLS authentication\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ will not be used. Valid values are `enable` or `disable` (optional; the default is `disable`).\n- `ca` - Certificate authority file for TLS client authentication (optional).\n- `cert` - Certificate for client authentication (optional).\n- `key` - Certificate Key for client authentication (optional).\n\n> 💡 **Note:** Using RabbitMQ host with AMQPS protocol will require enabling the TLS settings and passing the required parameters.\n\n#### Azure Workload Identity authentication\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use `TriggerAuthentication` CRD with `podIdentity.provider = azure-workload` and with `workloadIdentityResource` parameter, which will hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Currently, only HTTP protocol is supported for AKS Workload Identity.\n\n### Configuration examples\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672\n  vhostName: vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: vhostName\n      name: keda-rabbitmq-secret\n      key: vhostName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQP protocol with username and password authorization:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://localhost:5672/vhost (no username/password)\n  username: <username> # base64 encoded value of username\n  password: <password> # base64 encoded value of password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: username\n      name: keda-rabbitmq-secret\n      key: username\n    - parameter: password\n      name: keda-rabbitmq-secret\n      key: password \n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS authorization:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `MessageRate` and `QueueLength` triggers):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger) and enabled `useRegex`:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `DeliverGetRate` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: DeliverGetRate\n      value: \"30\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n\n#### HTTP protocol (with `PublishedToDeliveredRatio` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: PublishedToDeliveredRatio\n      value: \"1.1\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n\n#### HTTP protocol (with `PublishedToDeliveredRatio` trigger used together with `scalingModifiers`)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    name: p2d_ratio\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: PublishedToDeliveredRatio\n      value: \"1\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n  - type: rabbitmq\n    name: qlen\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"100\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n  advanced:\n    # Bind QueueLength and PublishedToDeliveredRatio together to control trigger value\n    scalingModifiers:\n      metricType: Value\n      # Trigger if either one of conditions is met:\n      # - publishing to delivery rate exceeds factor of 1.2\n      # - queue length contains more than 1.2K messages\n      formula: \"max(p2d_ratio, qlen/1000)\"\n      target: 1.2\n```\n\n#### HTTP protocol (with `ExpectedQueueConsumptionTime` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  pollingInterval: 1\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    name: eqct\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: ExpectedQueueConsumptionTime\n      value: \"20\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"myprimary\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.19/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars, SeleniumHQ\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration with default values represent.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: ''  # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`).\n      browserVersion: '' # Optional.\n      platformName: '' # Optional.\n      unsafeSsl: false # Optional.\n      activationThreshold: 0 # Optional.\n      nodeMaxSessions: 1 # Optional.\n      enableManagedDownloads: true # Optional.\n      capabilities: '' # Optional.\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional).\n- `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional).\n- `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional)\n\n**Trigger Authentication**\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional)\n- `accessToken` - Access token. This is required when `authType` is set a value. (Optional)\n\n### Example\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion`\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nNoted:\n- From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details.\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nWith above script, the request is sent to Grid. Via GraphQL response, it looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 0,\n      \"totalSlots\": 0\n    },\n    \"nodesInfo\": {\n      \"nodes\": []\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nIn Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata.\n\nWhen the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 1,\n      \"totalSlots\": 1\n    },\n    \"nodesInfo\": {\n      \"nodes\": [\n        {\n          \"id\": \"UUID-of-Node\",\n          \"status\": \"UP\",\n          \"sessionCount\": 0,\n          \"maxSession\": 1,\n          \"slotCount\": 1,\n          \"stereotypes\": \"[{\\\"slots\\\": 1, \\\"stereotype\\\": {\\\"browserName\\\": \\\"chrome\\\", \\\"browserVersion\\\": \\\"\\\", \\\"platformName\\\": \\\"Linux\\\"}}]\",\n          \"sessions\": []\n        }\n      ]\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nNow, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in.\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName`\n\nMoreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome-131\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:131.0\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: '131.0'\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-131\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-131\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '131.0'\n        unsafeSsl: 'true'\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '131.0')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n#### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads`\n\nIn image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node\n          - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS\n            value: \"true\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Scaler trigger param configuration should be aligned with Node stereotype.\n        enableManagedDownloads: \"true\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid\noptions.enable_downloads = True\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata with extra `capabilities`\n\nFor an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options\n          - name: SE_NODE_STEREOTYPE_EXTRA\n            value: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536\n        capabilities: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes\noptions.set_capability('myApp:version', 'beta')\noptions.set_capability('myApp:publish', 'public')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Firefox browser\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-firefox\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-firefox\n          image: selenium/node-firefox:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-firefox\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-firefox\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = FirefoxOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Edge browser\n\nSimilarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-edge\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-edge\n          image: selenium/node-edge:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-edge\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-edge\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = EdgeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions`\n\nIn case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n        - name: SE_NODE_OVERRIDE_MAX_SESSIONS\n          value: 'true'\n        - name: SE_NODE_MAX_SESSIONS\n          value: '4'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        nodeMaxSessions: 4\n        unsafeSsl: 'true'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n  graphql-username: base64 encoded value of GraphQL Username\n  graphql-password: base64 encoded value of GraphQL Password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n  - parameter: username\n    name: selenium-grid-secret\n    key: graphql-username\n  - parameter: password\n    name: selenium-grid-secret\n    key: graphql-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/solace-pub-sub-dm.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker - Direct Messaging\"\navailability = \"2.18+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker - Direct Messaging\"\ngo_file = \"solace_dm_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-direct-messaging` trigger that scales based on a Solace PubSub+ Event Broker direct messaging rates for all the clients in a message vpn that matches a common client name prefix.\n\n> &#128161; **Note:**\nThis trigger is for **Direct messaging** only, it provides the ability to scale the number of client instances automatically based upon transient metrics for shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length), all this metrics exists as long as the clients are connected.\n\nIf you need to use **Guaranteed messaging** (Solace PubSub+ Event Broker queue) you should use the `solace-event-queue` trigger.\n\n```yaml\n  triggers:\n  - type: solace-direct-messaging\n    metricType: Value\n    metadata:\n      solaceSempBaseURL:  \"https://solace_broker1:943,https://solace_broker2:943\"\n      messageVpn: \"message-vpn\"\n      clientNamePattern: \"client-name-pattern\"\n      unsafeSSL: \"true\"\n      queuedMessagesFactor: '3'\n      aggregatedClientTxMsgRateTarget: '600'      \n      aggregatedClientTxByteRateTarget: '0'\n      aggregatedClientAverageTxByteRateTarget: '0'\n      aggregatedClientAverageTxMsgRateTarget: '0'\n      usernameFromEnv: 'ENV_VAR_USER'\n      passwordFromEnv: 'ENV_VAR_PWD'\n    authenticationRef:\n      name: trigger-authentication-ref\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Comma separated list of Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`. (Required)\n\n- `messageVpn` - Message VPN hosted on the Solace broker from which the metrics will be collected. (Required)\n\n- `clientNamePattern` - Client name pattern that will be used to identify the clients that are consuming from a shared subscription. (Required). It will be used to match all the client names that match the expression: **' \\*client-name-pattern\\* '**\n\n- `unsafeSSL` - Flag to enable unsafe host urls (self signed certificates). (Default:  `false`, Optional)\n\n- `queuedMessagesFactor` - Flag to to increase weight on queued messages (D-1) and scale faster to avoid discarding messages. (Default:  `3`, Optional)\n\n- `aggregatedClientTxMsgRateTarget` - Target number messages per second the clients in the shared subscription are expected to consume, if the actual aggregated messages per second number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientTxByteRateTarget` - Target number bytes per second the clients in the shared subscription are expected to consume, if the actual aggregated bytes per second number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientAverageTxByteRateTarget` - Target average number messages per minute the clients in the shared subscription are expected to consume, if the actual aggregated messages per minute number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientAverageTxMsgRateTarget` - Target average number bytes per minute the clients in the shared subscription are expected to consume, if the actual aggregated bytes per minute number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `usernameFromEnv` - Environment variable set with SEMP user account. (Optional)\n\n- `passwordFromEnv` - Environment variable set with password for the user account. (Optional)\n\n**Parameter Requirements:**\n\n- Parameters resolving the target host and shared subscription are all **required:** `solaceSempBaseURL`, `messageVpn`, `clientNamePattern`\n\n- **At least** one of `aggregatedClientTxMsgRateTarget`, `aggregatedClientTxByteRateTarget`, `aggregatedClientAverageTxByteRateTarget` or  `aggregatedClientAverageTxMsgRateTarget` is **required**.\n\nIf more than one target values are present, calculation is done for each metric and the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n\nFor more details please see [Horizontal Pod Autoscaling - Algorithm details](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)\n\nThe `solace-direct-messaging` Scaler polls the Solace SEMP REST API to get transient metrics from connected clients. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the  trigger to function. \n\nThese values can be set in several different ways:\n  - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n  - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\nThe objects in the example below are declared in `namespace=solace`. It is not required to \ndo so. If you do define a namespace for the configuration objects, then they should all be declared \nin the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval:  3\n  cooldownPeriod:  60\n  #Always > 0 because is direct messaging!\n  minReplicaCount:  1\n  maxReplicaCount: 20\n  advanced:\n    restoreToOriginalReplicaCount: true\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n         #The stabilization window is used to restrict the flapping of replica count when the metrics used for scaling keep fluctuating.\n         #The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale.\n         #All desired states from the past 1 minutes (60secs) will be considered\n          stabilizationWindowSeconds: 60\n          #Policy (Pods) allows at most 1 replicas to be scaled down in 10 seconds.\n          policies:\n          - type:          Pods\n            value:         1\n            #Indicates the length of time in the past for which the policy must hold true\n            periodSeconds: 10\n        scaleUp:\n          stabilizationWindowSeconds: 0\n          #Policy (Pods) allows at most 3 replicas to be scaled up in 3 seconds.\n          policies:\n          - type:          Pods\n            value:         5\n            periodSeconds: 3\n          selectPolicy:    Max\n  triggers:\n  - type: solace-direct-messaging\n    #we don’t want to take the average of the given metric across all replicas, just the value\n    metricType: Value\n    metadata:\n      solaceSempBaseURL:  \"https://broker1.messaging.solace.cloud:943,https://broker2.messaging.solace.cloud:943\"\n      messageVpn: \"consumer_vpn\"\n      #all the clients that match this client name pattern will be considered for metric gathering\n      clientNamePattern: \"direct-messaging-simple\"\n      #to be able to use self signed certs\n      unsafeSSL: \"false\"\n      #to increase weight on queued messages and scale faster\n      #if there are messages queued means we are behind\n      queuedMessagesFactor: '3'\n      #Metrics\n      aggregatedClientTxMsgRateTarget: '600'      \n      aggregatedClientTxByteRateTarget: '0'\n      aggregatedClientAverageTxByteRateTarget: '0'\n      aggregatedClientAverageTxMsgRateTarget: '0'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD      \n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n**Note:**\nThis trigger is for **Guaranteed messaging** (Solace PubSub+ Event Broker queue) only, it provides the ability to scale the number of client instances automatically based upon metrics for a Solace PubSub+ Event Broker queue.\n\nIf you need to use **Direct messaging**, shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length) you should use the `solace-direct-messaging` trigger.\n\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint comma-separated host list in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **solaceSempBaseURL** can contain either a single URL or a comma-separated list of URLs.  If multiple URLs are provided, the scaler will iterate over the list until it is both able to connect the broker successfully AND the broker's messageVpn is in the **UP** state.  All brokers in the list will share the same authentication configuration.  This feature was primarily added to support Solace's Disaster Recovery Replication feature.\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/solarwinds.md",
    "content": "+++\ntitle = \"SolarWinds\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics from SolarWinds.\"\ngo_file = \"solarwinds_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solarwinds` trigger that scales based on metrics from SolarWinds.\n\n```yaml\ntriggers:\n- type: solarwinds\n  metadata:\n    host: https://api.na-01.cloud.solarwinds.com\n    targetValue: \"1\"\n    activationValue: \"3\"\n    metricName: \"k8s.pod.cpu.usage.seconds.rate\"\n    aggregation: \"AVG\"\n    intervalS: \"60\"\n    filter: \"k8s.deployment.name:my-deployment\"\n```\n\n**Parameter list:**\n\n- `host` - The SolarWinds API endpoint. (Example: `https://api.na-01.cloud.solarwinds.com`)\n- `targetValue` - Value to reach to start scaling. (This value can be an integer or float)\n- `activationValue` - Target value for activating the scaler. (Optional, Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds))\n- `metricName` - The name of the metric to monitor.\n- `aggregation` - The aggregation method to use. (Values: `COUNT`, `MIN`, `MAX`, `AVG`, `SUM`, `LAST`)\n- `intervalS` - The interval in seconds for the metric collection.\n- `filter` - The filter to apply to the metric data. (Optional, Examples below)\n  - `key1:value1 key2:value2` - Search using key values pairs with a delimiting space for an implicit AND\n  - `key:[value1,value2]` - Search using IN operator (key equals value1 or value2)\n  - `key:~value` - Search using CONTAINS operator\n  - `key>value1 key<value2` - Use comparative operators for number based keys such as (“=”, “>”, “<“, “<=”, “>=”) (key between value1 and value2)\n  - `NOT key:\"\"` - Search using NOT operator and EMPTY value (key is not empty)\n  - `entities(attribute:value)` - search using attributes of entities related to the metric data (metric values associated with entity having attribute equals value)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing the necessary credentials.\n\n**Credential based authentication:**\n\n- `apiToken` - The API token for accessing SolarWinds Observability. See [doc](https://documentation.solarwinds.com/en/success_center/observability/content/settings/api-tokens.htm) for more information.\n\n### Example\n\nHere is an example of a SolarWinds Scaler with authentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solarwinds-secret\n  namespace: default\ndata:\n  apiToken: <base64-encoded-api-token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solarwinds-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiToken\n      name: solarwinds-secret\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solarwinds-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: nginx\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 2\n  triggers:\n  - type: solarwinds\n    authenticationRef:\n      name: solarwinds-auth\n    metadata:\n      host: https://api.na-01.cloud.solarwinds.com\n      targetValue: \"3\"\n      activationValue: \"3\"\n      metricName: \"k8s.pod.cpu.usage.seconds.rate\"\n      aggregation: \"AVG\"\n      intervalS: \"60\"\n      filter: \"k8s.deployment.name:my-deployment\"\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/splunk-observability.md",
    "content": "+++\ntitle = \"Splunk Observability\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk Observability Cloud metrics.\"\ngo_file = \"splunk_observability_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk-observability` trigger that scales based on the result of a metric series queried from the Splunk Observability Cloud platform with a [SignalFlow query](https://dev.splunk.com/observability/docs/signalflow/).\n\n\n```yaml\ntriggers:\n  - type: splunk-observability\n    metadata:\n      # Required: SignalFlow query to retrieve the desired metric time series\n      query: \"data('demo.trans.latency').max().publish()\"\n      # Required: Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds\n      duration: \"10\"\n      # Required: Threshold to reach to start scaling\n      targetValue: \"400.1\"\n      # Required: Target value for activating the scaler\n      activationTargetValue: \"1.1\"\n      # Required: Specifies how the Metrics Time Series should be processed, options are \"min\" (minimum value), \"max\" (maximum value), and \"avg\" (average value)\n      queryAggregator: \"avg\"\n```\n\n**Parameter list:**\n\n- `query` - SignalFlow query for querying the desired metrics.\n- `duration` - Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds.\n- `targetValue` - Threshold to reach to start scaling.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `queryAggregator` - When querying metrics from Splunk Observability Cloud, initially a Metric Time Series (MTS) is returned, a list consisting of several datapoints. The 'queryAggregator' specifies how this series of metrics should be \"rolled up\". Valid values for this field are \"avg\", which returns the average, \"min\", which returns the minimum of the metrics in the series, and \"max\", which returns the maximum value.\n\n**Parameter list:**\n\n- `accessToken` - Splunk Observability Cloud Access Token.\n- `realm` - Splunk Observability Cloud Realm.\n\n## Configuration Example\n\nThe following example shows how to scale a simple NGINX employment with the help of KEDA and the Splunk Observability Cloud scaler:\n\n#### Simple NGINX employment\n\n```yaml\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n        - name: nginx\n          image: nginx:1.14.2\n          ports:\n            - containerPort: 80\n```\n\n#### Authentication\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-secrets\ndata:\n  accessToken: <base64-encoded Splunk Observability Cloud Access Token>\n  realm: <base64-encoded Splunk Observability Cloud Realm>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-splunk-secret\nspec:\n  secretTargetRef:\n    - parameter: accessToken\n      name: splunk-secrets\n      key: accessToken\n    - parameter: realm\n      name: splunk-secrets\n      key: realm\n```\n\n#### KEDA Scaler\n\n```yaml\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: nginx\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n    - type: splunk-observability\n      metricType: Value\n      metadata:\n        query: \"data('demo.trans.count', filter=filter('demo_host', 'server6'), rollup='rate').sum(by=['demo_host']).publish()\"\n        duration: \"10\"\n        queryValue: \"400.1\"\n        activationQueryValue: \"1.1\"\n        queryAggregator: \"max\" # 'min', 'max', or 'avg'\n      authenticationRef:\n        name: keda-trigger-auth-splunk-secret\n```"
  },
  {
    "path": "content/docs/2.19/scalers/splunk.md",
    "content": "+++\ntitle = \"Splunk\"\navailability = \"v2.15+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk saved search results.\"\ngo_file = \"splunk_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches).\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: splunk\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"1\"\n      activationValue: \"10\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n**Parameter list:**\n\n- `host` - Search API host and port. Example: `https://localhost:8089`.\n- `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `\"true\"`, `\"false\"`, Default: `\"false\"`, Optional)\n- `targetValue` - Value to reach to start scaling (This value can be a integer or float).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `savedSearchName` - Name of saved search that returns metric data for scaling.\n- `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`.\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication.\n\n> **Note:**\n>\n> `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API.\n\n**Parameter list:**\n\n- `username` - Splunk username authorized to access the search API.\n- `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`.\n- `password` - Password for supplied `username`. Conflicts with `apiToken`.\n\nThe user will need access to the saved search.\n\n### Examples\n\n### Username/password\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### API Token\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # admin\n  apiToken: <base64 encoded api token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: apiToken\n      name: splunk-creds\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### Full example using Splunk deployment\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: splunkconf\ndata:\n  default.yml: |\n    splunk:\n      conf:\n        - key: savedsearches\n          value:\n            directory: /opt/splunk/etc/users/admin/search/local\n            content:\n              my-saved-search-name:\n                action.email.useNSSubject: 1\n                action.webhook.enable_allowlist: 0\n                alert.track: 0\n                cron_schedule: '*/1 * * * *'\n                dispatch.earliest_time: -15m\n                dispatch.latest_time: now\n                display.general.type: statistics\n                display.page.search.tab: statistics\n                display.visualizations.show: 0\n                enableSched: 1\n                request.ui_dispatch_app: search\n                request.ui_dispatch_view: search\n                search: index=_internal | tail | stats count\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: splunk\nspec:\n  ports:\n    - port: 8000\n      targetPort: web\n      name: web-svc\n    - port: 8089\n      targetPort: 8089\n      name: api-svc\n  selector:\n    app: splunk\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: splunk\n  namespace: default\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: splunk\n  template:\n    metadata:\n      labels:\n        app: splunk\n    spec:\n      containers:\n      - name: splunk\n        image: splunk/splunk:9.2\n        ports:\n          - containerPort: 8000\n            name: web\n          - containerPort: 8089\n            name: api\n        env:\n          - name: SPLUNK_START_ARGS\n            value: --accept-license\n          - name: SPLUNK_PASSWORD\n            value: password\n        volumeMounts:\n          - name: splunkconf-volume\n            mountPath: /tmp/defaults\n      volumes:\n        - name: splunkconf-volume\n          configMap:\n            name: splunkconf\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx\n        ports:\n        - containerPort: 8080\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      unsafeSsl: \"true\"\n      targetValue: \"5\"\n      activationValue: \"5\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n"
  },
  {
    "path": "content/docs/2.19/scalers/sumologic.md",
    "content": "+++\ntitle = \"Sumo Logic\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"Monitoring & Analytics\"\ndescription = \"Scale applications based on Sumo Logic logs searches and metrics queries.\"\ngo_file = \"sumologic_scaler\"\n+++\n\n## Trigger Specification\n\nThis specification describes the `sumologic` trigger that scales based on Sumo Logic logs searches and metrics queries. The scaler supports three different query types:\n\n- **`logs`** - Scale based on Sumo Logic logs query results\n- **`metrics`** - Scale based on single Sumo Logic metrics query results  \n- **`metrics` (multi-query)** - Scale based on multiple combined Sumo Logic metrics queries\n\nHere are examples of the different trigger configurations:\n\n**Logs Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"   # Sumo Logic API endpoint\n    queryType: \"logs\"                   # Type must be \"logs\"\n    query: \"_view=my_view | count\"      # Your Sumo Logic logs query\n    resultField: \"_count\"               # Field to extract value from\n    timerange: \"15m\"                    # Lookback window\n    timezone: \"Asia/Kolkata\"            # Timezone (e.g., Asia/Kolkata)\n    queryAggregator: \"Max\"              # Aggregation method: Latest, Avg, Sum, Count, Min, Max\n    threshold: \"1000\"                   # Threshold for scaling\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Single Metrics Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"\n    queryType: \"metrics\"\n    query: \"metric=cpu.usage | avg\"\n    quantization: \"15s\"\n    rollup: \"Max\"\n    timerange: \"15m\"\n    timezone: \"Asia/Kolkata\"\n    queryAggregator: \"Max\"\n    threshold: \"50\"\n    maxRetries: \"3\"                     # Optional: Maximum retry attempts\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Multi-Metrics Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"\n    queryType: \"metrics\"\n    query.A: \"metric=requests_total | rate\"\n    query.B: \"metric=request_capacity\"\n    query.C: \"(#A / #B) * 100 along service\"\n    resultQueryRowID: \"C\"          # Which query result to extract\n    quantization: \"15s\"\n    rollup: \"Max\"\n    timerange: \"15m\"\n    timezone: \"Asia/Kolkata\"\n    queryAggregator: \"Max\"\n    threshold: \"75\"\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Parameter list:**\n\n**Common Parameters:**\n\n- `host` - Sumo Logic API endpoint URL (Based on your Geo).\n- `queryType` - Type of query. (Values: `logs`, `metrics`)\n- `query` - Sumo Logic query (for single queries).\n- `timerange` - Time range to evaluate the query.\n- `timezone` - Timezone for query execution. (Default: `UTC`, Optional)\n- `queryAggregator` - Aggregation method. (Values: `Latest`, `Avg`, `Sum`, `Count`, `Min`, `Max`, Default: `Avg`, Optional)\n- `threshold` - Target value for scaling.\n- `maxRetries` - Maximum number of retry attempts for API requests. (Default: `3`, Optional)\n\n**Logs Query Specific Parameters:**\n\n- `resultField` - Field from query results to extract the scaling metric. (Required when `queryType` is `logs`)\n- `logsPollingInterval` - Polling interval for log search job. (Default: `1s`, Optional)\n\n**Metrics Query Specific Parameters:**\n\n- `quantization` - Granularity of data points. (Required when `queryType` is `metrics`)\n- `rollup` - Metrics rollup type. (Values: `Avg`, `Sum`, `Min`, `Max`, `Count`, Default: `Avg`, Optional)\n\n**Multi-Metrics Query Specific Parameters:**\n\n- `query.A`, `query.B`, `query.C` etc - Multi-stage queries, where later queries can refer to earlier ones. (Required for multi-metrics queries)\n- `resultQueryRowID` - Which final query (`A`, `B`, `C`, etc.) to use for scaling. (Required for multi-metrics queries)\n\n## Authentication Parameters\n\nYou must configure a `TriggerAuthentication` resource to authenticate with Sumo Logic.\n\n**Prerequisites:**\n- A Sumo Logic Access ID and Access Key\n\nAuthentication is handled through a Kubernetes `Secret` combined with a `TriggerAuthentication`:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: sumologic-auth-secret\ndata:\n  accessID: <base64-encoded-accessID>\n  accessKey: <base64-encoded-accessKey>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-sumologic\nspec:\n  secretTargetRef:\n    - parameter: accessID\n      name: sumologic-auth-secret\n      key: accessID\n    - parameter: accessKey\n      name: sumologic-auth-secret\n      key: accessKey\n```\n\n### Example\n\nHere is a complete example that demonstrates autoscaling based on Sumo Logic logs query:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: sumologic-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: sumologic\n    metadata:\n      host: \"https://api.sumologic.com\"\n      queryType: \"logs\"\n      query: \"_view=error_logs | count\"\n      resultField: \"_count\"\n      timerange: \"5m\"\n      threshold: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-sumologic\n```\n\n### Notes\n\n- `pollingInterval` controls how often KEDA polls Sumo Logic.\n- `cooldownPeriod` controls how long KEDA waits before scaling down.\n- `MetricType:` The scaler supports both `AverageValue` and `Value` metric types.\n- Ensure that the Sumo Logic user has **appropriate access** to the queries being executed.\n\n"
  },
  {
    "path": "content/docs/2.19/scalers/temporal.md",
    "content": "+++\ntitle = \"Temporal\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Temporal task queue.\"\ngo_file = \"temporal_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `temporal` trigger that scales based on a Temporal task queue.\n\n```yaml\ntriggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n      queueTypes: workflow # optional\n      buildId: 1.0.0 # optional\n      selectAllActive: \"false\" # optional\n      selectUnversioned: \"false\" # optional\n      minConnectTimeout: \"5\" # optional\n      unsafeSsl: \"false\" # optional\n      tlsServerName: \"custom-tls-servername\" # optional\n```\n\n**Parameter list:**\n\n- `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `<hostname>:<port>`. (Required)\n- `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional)\n- `namespace` - The namespace of the temporal service. (Default:`default`, Optional)\n- `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found  [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional)\n- `taskQueue` - This parameter specifies the task queue name. (Required)\n- `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional)\n- `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional)\n- `selectAllActive` - Include all active versions (Default:`false`, Optional)\n- `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional)\n- `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional)\n- `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional)\n- `tlsServerName` - The custom tls server name (Optional)\n\n> 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero.\n  This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog.\n  Consequently, scaling to zero could result in undesirable behavior,\n  such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA).\n  By fine-tuning the configurations, you can prevent premature scaling to zero,\n  ensuring that resources remain available for in-flight tasks or workloads with minimal throughput.\n\n\n**Authentication Parameters:**\n\nTemporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication:\n\n- `apiKey` - API key for authentication with temporal cloud. (Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: temporal-secret\n  namespace: default\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-temporal\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: apiKey\n    name: temporal-secret\n    key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: workload-scaledobject\n  pollingInterval: 5\n  cooldownPeriod:  10\n  minReplicaCount: 0\n  maxReplicaCount: 5\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 10\n  triggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n    authenticationRef:\n      name: keda-trigger-auth-temporal\n```\n"
  },
  {
    "path": "content/docs/2.19/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.19/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.2/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.2/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.2/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.2/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.2/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam  # Optional. Default: none\n  secretTargetRef:                                    # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {secret-name}                               # Required.\n    key: {secret-key-name}                            # Required.\n  env:                                                # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {env-name}                                  # Required.\n    containerName: {container-name}                   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                     # Optional.\n    address: {hashicorp-vault-address}                # Required.\n    authentication: token | kubernetes                # Required.\n    role: {hashicorp-vault-role}                      # Optional.\n    mount: {hashicorp-vault-mount}                    # Optional.\n    credential:                                       # Optional.\n      token: {hashicorp-vault-token}                  # Optional.\n      serviceAccount: {path-to-service-account-file}  # Optional.\n    secrets:                                          # Required.\n    - parameter: {scaledObject-parameter-name}        # Required.\n      key: {hashicorp-vault-secret-key-name}           # Required.\n      path: {hashicorp-vault-secret-path}              # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.2/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interfaces:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nFew things to notice:\n\n- Lack of `Close` method as the GRPC connection defines the lifetime of the scaler\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\nFor `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.2/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval: 30                                # Optional. Default: 30 seconds\n  cooldownPeriod:  300                               # Optional. Default: 300 seconds\n  minReplicaCount: 0                                 # Optional. Default: 0\n  maxReplicaCount: 100                               # Optional. Default: 100\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n```yaml\n  minReplicaCount: 0   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource.\n\n---\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.2/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) {\n>\t\t\tpendingJobs++\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n"
  },
  {
    "path": "content/docs/2.2/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.2/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    ```sh\n    helm install keda kedacore/keda  --version 2.2.0 --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster you can run one of the following:\n\n```sh\nhelm uninstall keda -n keda\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.2.0`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.2.0/keda-2.2.0.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.2.0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.2.0 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.2.0`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.2.0/keda-2.2.0.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.2.0.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.2.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.2/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.2/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.2/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.2/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n"
  },
  {
    "path": "content/docs/2.2/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.2 has been tested on Kubernetes v1.16.0 or above.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.This is only supported as of KEDA v2.6 if you are using our Helm chart.                                                                                    |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable to your desired timeout in milliseconds. For example, on Linux/Mac/Windows WSL2 operating systems, you'd use this command to set to 1 second:\n\n```shell\nexport KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAnd on Windows Powershell, you'd use this command:\n\n```shell\n$env:KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAll applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported.\n"
  },
  {
    "path": "content/docs/2.2/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                               | Type      | Description                                                                                                                 |\n|-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                 | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                    | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`           | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`              | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`               | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                  | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                  | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`        | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                   | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`        | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`      | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded` | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                                   |\n| `ClusterTriggerAuthenticationDeleted`| `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                                     |\n"
  },
  {
    "path": "content/docs/2.2/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.2/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.2/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - No. of replicas will not exceed the number of partitions on a topic. That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag.\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.2/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName\n    dimensionName: QueueName\n    # Required: Dimension Value - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Metric Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.2/concepts/authentication/).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets       # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n\n> For the purposes of scaling, \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing.\n\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\nnotice = \"As of now, the Event Hub scaler only supports reading checkpoints from Blob Storage, as well as scaling only Event Hub applications written in C#, Java, Python or created with Azure Functions.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of event hub consumer. (Default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed when a using an Event Hub application written in dotnet or java, and not an Azure function.\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.2/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: kube_pod_status_ready\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.2/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Password Authentication:**\n\n- `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager.\n- `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authMode` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a  metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a  metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a  metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server with database used.It would be written like this \"portnumber/dbname\"\n      port: \"27017/test\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server with the `dbName` separated by slash `/`.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `password` - Password for the configured user to login to MongoDB server.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. The default for MSSQL is 1433.\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the `database` value (if specified), or the `host` value, or will be in the form `mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment\n variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.2/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Metric name to use.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100\" # message backlog or publish/sec. target per instance\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.2/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.2/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.20/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\ndescription = \"How you can start with KEDA as new user\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. \n\nUse the navigation bar on the left to learn more about KEDA's architecture  and how to deploy and use KEDA.\n\n## Where to go\n\nWhat is your involvement with KEDA?\n\n| Role                      | Documentation                                                                                                                                                |\n|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| User                      | This documentation is for users who want to deploy KEDA to scale Kubernetes.                                                                                 |\n| Core Contributor          | To contribute to the core KEDA project see the [KEDA GitHub repo](https://github.com/kedacore/keda).                                                         |\n| Documentation Contributor | To add or contribute to these docs, or to build and serve the documentation locally, see the [keda-docs GitHub repo](https://github.com/kedacore/keda-docs). |\n| Other Contributor         | See the [KEDA project on GitHub](https://github.com/kedacore/) for other KEDA repos, including project governance, testing, and external scalers.            |\n"
  },
  {
    "path": "content/docs/2.20/addons/_index.md",
    "content": "+++\ntitle = \"Add-ons\"\nweight = 3\n+++\n\nAdd-ons extend KEDA with support for specific use cases beyond the built-in scalers.\n\n## HTTP Add-on\n\nThe [HTTP Add-on](/http-add-on/latest/) enables autoscaling of HTTP-based workloads.\nIt intercepts incoming HTTP requests and scales the target workload based on request volume.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\n> ⚠️ **WARNING:** [`aws-eks` auth has been deprecated](https://github.com/kedacore/keda/discussions/5343) and support for it will be removed from KEDA on v3. We strongly encourage the migration to [`aws` auth](./aws.md).\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/aws-secret-manager.md",
    "content": "+++ \ntitle = \"AWS Secret Manager\" \n+++\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, and an optional version parameter, defaulting to the latest version if unspecified.\n\n### Configuration\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}                    # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: {key-in-k8s-secret}               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optionqal\n```\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/aws.md",
    "content": "+++\ntitle = \"AWS (IRSA) Pod Identity Webhook\"\n+++\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use AWS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional. If not set, 'keda' is default value. Mutually exclusive with 'roleArn' (if set)\n```\n\n**Parameter list:**\n\n- `roleArn` - Role ARN to be used by KEDA. If not set the IAM role which the KEDA operator uses will be used. Mutually exclusive with `identityOwner: workload`\n- `identityOwner` - Owner of the identity to be used. (Values: `keda`, `workload`, Default: `keda`, Optional)\n\n> ⚠️ **NOTE:** `podIdentity.roleArn` and `podIdentity.identityOwner` are mutually exclusive, setting both is not supported.\n\n## How to use \n\nAWS IRSA will give access to pods with service accounts having appropriate annotations. ([official docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) You can set these annotations on the KEDA Operator service account.\n\nThis can be done for you during deployment with Helm with the following flags: \n\n1. `--set podIdentity.aws.irsa.enabled=true`\n2. `--set podIdentity.aws.irsa.roleArn={aws-arn-role}`\n\nYou can override the default KEDA operator IAM role by specifying an `roleArn` parameter under the `podIdentity` field. This allows end-users to use different roles to access various resources which allows for more granular access than having a single IAM role that has access to multiple resources.\n\nIf you would like to use the same IAM credentials as your workload is currently using, `podIdentity.identityOwner` can be set with the value `workload` and KEDA will inspect the workload service account to check if IRSA annotation is there and KEDA will assume that role.\n\n**Regional STS endpoints**\n\n- If you’re using **`identityOwner: keda`** (the operator’s IRSA role), annotate the **`keda-operator`** ServiceAccount in the `keda` namespace.  \n- If you’re using **`identityOwner: workload`** (the default), annotate **your workload’s** ServiceAccount (the one your Deployment uses).\n\n```yaml\napiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: <SERVICE_ACCOUNT_NAME>\n  namespace: <NAMESPACE>\n  annotations:\n    eks.amazonaws.com/role-arn: <YOUR_IRSA_ROLE_ARN>\n    # Required for regional STS endpoints (e.g. eu-west-1)\n    eks.amazonaws.com/sts-regional-endpoints: \"true\"\n ```\n\n### When do you need regional STS endpoints?\n\nBy default, AWS STS calls go to the global endpoint (`sts.amazonaws.com`).  \nSome regions (for example **eu-west-1**, **ap-northeast-1**, **ap-southeast-2**) require or strongly recommend using their **regional STS endpoint** (e.g. `sts.eu-west-1.amazonaws.com`).  \n\nIf you see errors like:\n\n```\nAccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n```\n\nwhile your IAM trust policy looks correct, you likely need to enable regional endpoints with:\n\n```yaml\nannotations:\n  eks.amazonaws.com/sts-regional-endpoints: \"true\"\n```\n\n👉 Use this setting whenever you are running in a region that does **not** support the global STS endpoint or where AWS recommends regional STS for latency and availability.\n\n## AssumeRole or AssumeRoleWithWebIdentity?\n\nThis authentication automatically uses both, falling back from [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) if the first one fails. This extends the capabilities because KEDA doesn't need `sts:AssumeRole` permission if you are already working with [WebIdentities](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html); in this case, you can add a KEDA service account to the trusted relations of the role.\n\n## Setting up KEDA role and policy\n\nThe [official AWS docs](https://aws.amazon.com/es/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) explain how to set up a basic configuration for an IRSA role. The policy changes depending on if you are using the KEDA role (`podIdentity.roleArn` is not set) or workload role (`podIdentity.roleArn` sets a RoleArn or `podIdentity.identityOwner` sets to `workload`).\n\n### Using KEDA role to access infrastructure\n\nAttach the desired policies to KEDA's role, granting the access permissions that you want to provide. For example, this could be a policy to use with SQS:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"sqs:GetQueueAttributes\",\n            \"Resource\": \"arn:aws:sqs:*:YOUR_ACCOUNT:YOUR_QUEUE\"\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRoleWithWebIdentity\nIn this case, KEDA will use its own (k8s) service account to assume workload role (and to use workload's role attached policies). This scenario requires that KEDA service account is trusted for requesting the role using AssumeRoleWithWebIdentity.\n\nThis is an example of how role policy could look like:\n\n```json\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            ... YOUR WORKLOAD TRUSTED RELATION ...\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Principal\": {\n                \"Federated\": \"YOUR_OIDC_ARN\"\n            },\n            \"Action\": \"sts:AssumeRoleWithWebIdentity\",\n            \"Condition\": {\n                \"StringEquals\": {\n                    \"YOUR_OIDC:sub\": \"system:serviceaccount:keda:keda-operator\",\n                    \"YOUR_OIDC:aud\": \"sts.amazonaws.com\"\n                }\n            }\n        }\n    ]\n}\n```\n\n### Using KEDA role to assume workload role using AssumeRole\n\nIn this case, KEDA will use its own role to assume the workload role (and to use workload's role attached policies). This scenario is a bit more complex because we need to establish a trusted relationship between both roles and we need to grant to KEDA's role the permission to assume other roles.\n\nThis is an example of how KEDA's role policy could look like:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_1:role/ROLE_NAME\"\n      ]\n    },\n    {\n      \"Effect\": \"Allow\",\n      \"Action\": \"sts:AssumeRole\",\n      \"Resource\": [\n        \"arn:aws:iam::ACCOUNT_2:role/*\"\n      ]\n    }\n  ]\n}\n```\nThis can be extended so that KEDA can assume multiple workload roles, either as an explicit array of role ARNs, or with a wildcard.\nThis policy attached to KEDA's role will allow KEDA to assume other roles, now you have to allow the workload roles you want to use all allow to being assumed by the KEDA operator role. To achieve this, you have to add a trusted relation to the workload role:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      // Your already existing relations\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      // ...\n    },\n    {\n      \"Sid\": \"\",\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\n\n#### Cross-account isolation with ExternalId\n\nIn multi-tenant environments where a shared KEDA operator assumes roles in different accounts, you can enforce [confused deputy protection](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) by requiring an `ExternalId` in the workload role's trust policy.\n\nAdd the `sts:ExternalId` condition to the workload role's trust policy:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"AWS\": \"arn:aws:iam::ACCOUNT:role/KEDA_ROLE_NAME\"\n      },\n      \"Action\": \"sts:AssumeRole\",\n      \"Condition\": {\n        \"StringEquals\": {\n          \"sts:ExternalId\": \"YOUR_UNIQUE_EXTERNAL_ID\"\n        }\n      }\n    }\n  ]\n}\n```\n\nThen pass the `externalId` via `TriggerAuthentication.podIdentity.externalID` alongside `roleArn`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: aws-trigger-auth\n  namespace: my-namespace\nspec:\n  podIdentity:\n    externalID: \"YOUR_UNIQUE_EXTERNAL_ID\"\n    roleArn: \"arn:aws:iam::ACCOUNT:role/WORKLOAD_ROLE\"\n```\n\n> ℹ️ **NOTE:** `externalId` is optional. If not set, KEDA calls `AssumeRole` without an ExternalId, which is the default behavior. `externalId` is only applied to `AssumeRole` — `AssumeRoleWithWebIdentity` does not accept an ExternalId parameter.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) or [**Azure Managed Identity**](https://docs.microsoft.com/azure/active-directory/managed-identities-azure-resources/overview) without having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload                # Optional. Default: none\n  identityId: <identity-id>               # Optional. Default: ClientId from annotation on service-account.\n  identityTenantId: <tenant-id>           # Optional. Default: TenantId from annotation on service-account.\n  identityAuthorityHost: <authority-host> # Optional. Default: AZURE_AUTHORITY_HOST environment variable which is injected by azure-wi-webhook-controller-manager.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\nAdditionally, there might be a need for Azure Workload Identity to authenticate across tenants and/or clouds (e.g., AzureCloud, AzureChinaCloud, AzureUSGovernment, AzureGermanCloud). To authenticate against a different tenant within the same cloud, you can specify the `identityTenantId` parameter under the `podIdentity` field. To authenticate against a tenant within a different cloud, you must specify both the `identityTenantId` and `identityAuthorityHost` parameters under the `podIdentity` field. This is useful when you have resources in different tenants or clouds that is different from the tenant and cloud where the KEDA Operator is running.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n\n### Case 3\n\nSimilar to the previous scenario, you also have separate identities for your workloads but in different tenants:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A in Tenant A.\n- Workload B's identity with access to Service Bus B in Tenant B.\n\nIn this case, you are overriding the default identity and tenant set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId` and `.spec.podIdentity.identityTenantId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId and identityTenantId for Workload A and Workload B's for Workload B). It is important to note that within this scenario, KEDA's service account must be federated with all the identities in each tenant.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/bound-service-account-token.md",
    "content": "+++\ntitle = \"Bound service account token\"\n+++\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n## Permissions for KEDA to request service account tokens\n\nBy default, the KEDA operator does not have the necessary permissions to request service account tokens from an arbitrary service account. This is to prevent a privilege escalation where a bad actor could use KEDA to request tokens on behalf of any service account in the cluster.\n\nTo allow KEDA to request tokens from a service account, you must grant the `keda-operator` service account the necessary permissions using RBAC. This can be done by creating a `Role` and a `RoleBinding` in the service account's namespace to allow the `keda-operator` service account the `create` permission on the namespaced `serviceaccounts/token` subresource.\n\nHere's a minimal example of a `Role` and `RoleBinding` that grants the necessary permissions for the KEDA operator to request and use tokens from the namespaced `my-service-account` service account.\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator\n  namespace: my-namespace # Replace with the namespace of the service account\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - my-service-account # Replace with the name of the service account\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding\n  namespace: my-namespace # Replace with the namespace of the service account\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda # Assuming the keda-operator service account is in the keda namespace\n```\n\nAfter applying similar restrictive permissions in your cluster, you can create the `TriggerAuthentication` resource that references the service account name, allowing KEDA to request and use tokens on your behalf with your scaler. Note that the service account must also have the necessary Kubernetes API permissions to perform the actions required by the scaler, such as querying metrics or managing resources, if the scaler delegates authentication to the Kubernetes API.\n\n### Usage in keda-charts\n\nIf you use Helm Charts to deploy KEDA, you can supply namespaced names of the service accounts that KEDA request tokens from by setting the `boundServiceAccountToken` field in the `values.yaml` file. For example:\n\n```yaml\n# values.yaml\npermissions:\n  operator:\n    restrict:\n      serviceAccountTokenCreationRoles:\n      - name: myServiceAccount\n        namespace: myServiceAccountNamespace\n```\n\nThis will create the necessary `Role` and `RoleBinding` in the `myServiceAccountNamespace` namespace:\n\n```yaml\napiVersion: rbac.authorization.k8s.io/v1\nkind: Role\nmetadata:\n  name: keda-operator-token-creator-myServiceAccount\n  namespace: myServiceAccountNamespace\nrules:\n- apiGroups:\n  - \"\"\n  resources:\n  - serviceaccounts/token\n  verbs:\n  - create\n  resourceNames:\n  - myServiceAccount\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: RoleBinding\nmetadata:\n  name: keda-operator-token-creator-binding-myServiceAccount\n  namespace: myServiceAccountNamespace\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: Role\n  name: keda-operator-token-creator-myServiceAccount\nsubjects:\n- kind: ServiceAccount\n  name: keda-operator\n  namespace: keda\n```\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/configmap.md",
    "content": "+++\ntitle = \"Config Map\"\n+++\n\nYou can pull information into the trigger by defining the `name` of the Kubernetes `ConfigMap` and the `key` to use.\n\n```yaml\nconfigMapTargetRef:                       # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-configmap-resource-name # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the `ScaledObject`, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/file-path.md",
    "content": "+++\ntitle = \"File path\"\n+++\n\nYou can read authentication parameters from files mounted in the KEDA operator pod using the `filePath` option. This feature requires the KEDA operator to be configured with a root path for file access.\n\n## Security Constraints\n\nThe `filePath` feature has important security constraints:\n\n- **Requires root path configuration** - The KEDA operator must be started with `--filepath-auth-root-path` to define the allowed directory\n- **Path validation** - All file paths are validated to ensure they resolve within the configured root path, preventing access to sensitive system files like service account tokens\n- **Relative paths** - The `filePath` in `ClusterTriggerAuthentication` is treated as a relative path under the configured root path\n\n## Operator Configuration\n\nThe KEDA operator requires a command-line argument to enable file-based authentication:\n\n```bash\n--filepath-auth-root-path=/path/to/allowed/files\n```\n\nThis path should point to a directory where credential files are mounted. The operator will only read files from within this directory.\n\n## Example\n\nFirst, ensure the KEDA operator has the root path configured. Then create a `ClusterTriggerAuthentication` referencing files:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: file-based-auth\nspec:\n  filePath:\n    - parameter: apiKey           # Required - Defined by the scale trigger\n      path: credentials/api-key   # Required - Path relative to filepath-auth-root-path\n```\n\n**Assumptions:**\n- The path is relative to the `--filepath-auth-root-path` configured for the KEDA operator\n- The credential file exists at `{filepath-auth-root-path}/credentials/api-key`\n- The file contains the raw credential value (not JSON encoded)\n- The file path should match the actual file name, including any extension if present (e.g., `credentials/api-key.txt` if the file is named `api-key.txt`)\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/gcp-secret-manager.md",
    "content": "+++\ntitle = \"GCP Secret Manager\"\n+++\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Steps to create the IAM Service Account Kubernetes secret\n- Create a new GCP IAM service account. In case you would like to use an existing service account, you can skip this step.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n\n  Replace the following:\n\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n- Ensure that your IAM service account has [roles](https://cloud.google.com/iam/docs/understanding-roles) which provide sufficient [permissions](https://cloud.google.com/iam/docs/permissions-reference) needed to retrieve the secrets, such as the [Secret Manager Secret Accessor](https://cloud.google.com/secret-manager/docs/access-control#secretmanager.secretAccessor). You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/secretmanager.secretaccessor.\n\n- Either setup [GCP workload identity](./gcp-workload-identity) or create a JSON key credential for authenticating with the service account:\n\n  ```shell\n  gcloud iam service-accounts keys create KEY_FILE \\\n    --iam-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com\n  ```\n\n  Replace the following:\n\n  KEY_FILE: the file path to a new output file for the private key in your local machine. \\\n  GSA_NAME: the name of your IAM service account. \\\n  PROJECT_ID: your Google Cloud project ID.\n\n- Create a Kubernetes secret for storing the SA key file in the same namespace where you will create the `TriggerAuthentication` resource:\n\n  ```shell\n  kubectl create secret generic NAME --from-file=KEY=KEY_FILE -n NAMESPACE\n  ```\n\n  Replace the following:\n\n  NAME: name of the Kubernetes secret resource. \\\n  KEY: Kubernetes secret key for the SA. \\\n  KEY_FILE: the file path to the SA in your local machine. \\\n  NAMESPACE: the namespace in which the `TriggerAuthentication` resource will be created.\n\nNow you can create the `TriggerAuthentication` resource which references the secret-name and key for the SA.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to set up Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to set up workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more.\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method. There's multiple methods for authentication; For kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) or provide the serviceAccountName that can authenticate to kubernetes in the namespace of the ScaledObject/ScaledJob resource (usually `default`). If using serviceAccountName make sure to grant KEDA Operator `create serviceaccounts/token` permissions. This is set in the helm chart via `permissions.operator.restrict.allowAllServiceAccountTokenCreation=true` For token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n> Since version `1.5.0` Vault secrets backend **version 2** is supported. \n> The support for Vault secrets backend **version 1** was added on version `2.10`.\n\n```yaml\nhashiCorpVault:                                               # Optional.\n  address: {hashicorp-vault-address}                          # Required.\n  namespace: {hashicorp-vault-namespace}                      # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                          # Required.\n  role: {hashicorp-vault-role}                                # Optional.\n  mount: {hashicorp-vault-mount}                              # Optional.\n  credential:                                                 # Optional.\n    token: {hashicorp-vault-token}                            # Optional. Authenticate to vault via a supplied token\n    serviceAccount: {path-to-service-account-file}            # Optional. Authenticate to vault via JWT token in keda operator pod\n    serviceAccountName: {service-account-name-for-auth}       # Optional. Requires serviceaccounts/token create permissions. Authenticate to vault via JWT token from service account in ScaledObject/ScaledJob's namespace\n  secrets:                                                    # Required.\n  - parameter: {scaledObject-parameter-name}                  # Required.\n    key: {hashicorp-vault-secret-key-name}                    # Required.\n    path: {hashicorp-vault-secret-path}                       # Required.\n    type: {hashicorp-vault-secret-type}                       # Optional. Default to `\"\"`. Allowed values: `secret`, `secretV2`, `pki`\n    pkidata: {hashicorp-vault-secret-pkidata}                 # Optional. Data to be send with the secret  if `hashicorp-vault-secret-type` is pki request\n      commonName: {hashicorp-vault-secret-pkidata-commonName} # Optional.\n      altNames: {hashicorp-vault-secret-pkidata-altNames}     # Optional.\n      ipSans: {hashicorp-vault-secret-pkidata-ipSans}         # Optional.\n      uriSans: {hashicorp-vault-secret-pkidata-uriSans}       # Optional.\n      otherSans: {hashicorp-vault-secret-pkidata-otherSans}   # Optional.\n      ttl: {hashicorp-vault-secret-pkidata-ttl}               # Optional.\n      format: {hashicorp-vault-secret-pkidata-format}         # Optional.\n```\n\n### Example\nVault Secret can be used to provide authentication for a Scaler. If using the [Prometheus scaler](https://keda.sh/docs/2.3/scalers/prometheus/), mTls can be used by the `ScaledObject` to authenticate to the Prometheus server. The following example would request a certificate to Vault dynamically.\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-mame}\n  namespace: default\nspec:\n  hashiCorpVault:\n    address: {hashicorp-vault-address}\n    authentication: token\n    credential:\n      token: {hashicorp-vault-token}\n    secrets:\n      - key: \"ca_chain\"\n        parameter: \"ca\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"private_key\"\n        parameter: \"key\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n      - key: \"certificate\"\n        parameter: \"cert\"\n        path: {hashicorp-vault-secret-path}\n        type: pki\n        pki_data:\n          common_name: {hashicorp-vault-secret-pkidata-commonName}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: { trigger-authentication-mame }\n```\n"
  },
  {
    "path": "content/docs/2.20/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.20/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a tool that helps [Kubernetes](https://kubernetes.io) scale applications based on real-world events. It was created by Microsoft and Red Hat. With KEDA, you can adjust the size of your containers automatically, depending on the workload—like the number of messages in a queue or incoming requests.\n\nIt’s lightweight and works alongside Kubernetes components like the Horizontal Pod Autoscaler (HPA). It doesn’t replace anything but adds more functionality. You can choose which apps to scale with KEDA while leaving others untouched. This makes it flexible and easy to integrate with your existing setup.\n\n## How KEDA works\n\nKEDA monitors external event sources, like message queues, databases, or APIs, and automatically adjusts the number of running pods based on real-time demand. When events arrive, KEDA scales your workload up to handle the load. When things go quiet, it scales back down, all the way to zero if needed.\n\nIt does this by working alongside Kubernetes' existing Horizontal Pod Autoscaler rather than replacing it. KEDA feeds the HPA with external metrics, extending it beyond CPU and memory to any event source you can connect to. The result is an application that responds to actual workload rather than just infrastructure signals.\n\nFor batch workloads, KEDA takes a different approach: instead of scaling a running deployment up or down, it creates new Kubernetes Jobs in response to events, for example, one job per message in a queue.\n\n## KEDA Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-new.png)\n\nKEDA runs three components inside the Kubernetes cluster, each with a distinct responsibility:\n\n* **keda-operator** watches KEDA resources like your ScaledObjects and manages the full HPA lifecycle. It is also directly responsible for scaling a workload between zero and one replica—bringing an idle deployment back to life when events arrive, or scaling it down to zero when there is nothing to process.\n* **keda-metrics-apiserver** exposes the external metrics (polled from event sources such as Kafka, RabbitMQ, Elasticsearch, or SQS) to the Kubernetes HPA via the Kubernetes API Server. The HPA queries these metrics to decide how many replicas are needed above one.\n* **keda-admission-webhooks** validate every KEDA resource like your ScaledObject at the moment it is applied, catching configuration mistakes, such as two ScaledObjects targeting the same deployment, before they cause problems at runtime.\n\nThe scaling flow works in two complementary tracks:\n\n1. **Zero-to-one and one-to-zero scaling** is handled directly by the keda-operator. When an event source becomes active, the operator brings the deployment up from zero replicas; when it goes idle again, the operator scales it back down to zero.\n2. **One-to-N and N-to-one scaling** is delegated to the Horizontal Pod Autoscaler. The keda-operator creates and manages the HPA resource; the HPA queries external metrics through the Kubernetes API Server (served by the keda-metrics-apiserver), and adjusts the number of running pods accordingly.\n\nThe ReplicaSet inside the Deployment translates the desired replica count set by both tracks into actual running pods.\n\n## KEDA Custom Resources (CRDs)\n\nKEDA uses **Custom Resource Definitions (CRDs)** to manage scaling behavior:\n\n* **ScaledObject**: Links your app (like a **Deployment** or **StatefulSet**) to an external event source, defining how scaling works.\n* **ScaledJob**: Handles batch processing tasks by scaling Jobs based on external metrics.\n* **TriggerAuthentication**: Provides secure ways to access event sources, supporting methods like environment variables or cloud-specific credentials.\n\nThese CRDs give you control over scaling while keeping your apps secure and responsive to demand.\n\n## Scaling Deployments, StatefulSets, and Custom Resources\n\nKEDA goes beyond CPU or memory-based scaling by connecting to external data sources like message queues, databases, or APIs. This means your apps scale in real-time based on actual workload needs.\n\n### Scaling Deployments and StatefulSets\n\nWith KEDA, you can scale Deployments and StatefulSets easily. By creating a ScaledObject, you link your workload to an event source, like a queue or request rate. KEDA adjusts the number of instances based on demand.\n\nDeployments are perfect for stateless apps that need quick scaling. StatefulSets are great for apps requiring stable storage or identity, like databases. KEDA ensures your resources are used efficiently while keeping up with demand.\n\n> Note: When using CPU or Memory triggers, the metric flow is different. KEDA still creates and manages the HPA, but the HPA fetches CPU and Memory data directly from the Kubernetes `metrics-server`, not via the `keda-metrics-apiserver`. As a result, scale-to-zero is not supported with CPU or Memory triggers: without running pods, there are no metrics to observe, so KEDA has no signal to scale back up from zero.\n\n### Scaling Custom Resources\n\nKEDA also supports custom Kubernetes resources. You set up a ScaledObject tailored to your resource and connect it to an event trigger, like database changes. From there, you define the scaling limits, and KEDA handles the rest, ensuring your custom app scales dynamically.\n\n### Scaling Jobs\n\nKEDA can scale Kubernetes Jobs for batch processing. By creating a ScaledJob, you link the task to an external event, like queue size. KEDA adjusts the number of job instances in real-time, cleaning up completed jobs automatically. This ensures you only use resources when needed.\n\n### Authentication\n\nKEDA supports secure connections to external event sources using TriggerAuthentication. You can configure it to work with secrets, cloud-native authentication like AWS IAM role, or Azure Active Directory. This keeps your connections secure and your data safe.\n\n### External Scalers\n\nKEDA connects to various services, like message queues or cloud APIs, through scalers. These fetch real-time metrics to determine when and how to scale. KEDA includes built-in scalers for popular services, but you can create custom ones if needed. This lets your workloads respond to real-world demand effortlessly.\n\n### Consuming Raw Scaler Metrics Externally\n\nKEDA also allows consuming the internal metrics (coming from internal or external scalers) to interested 3rd parties. This feature is exposed using gRPC server stream API and needs to be first enabled by setting `RAW_METRICS_GRPC_PROTOCOL` to \"`enabled`\". Then one can subscribe to a metric identified by ScaledObject/ScaledJob name, namespace and trigger name using any gRPC client (example with [grpcurl](https://github.com/kedacore/keda/pull/7093#issuecomment-3333530716)).\n\nYou can control when raw metrics are sent using the `RAW_METRICS_MODE` environment variable:\n\n* `all` or `\"\"` (empty): Sends all raw metrics, both when the metrics server requests them (HPA) and during the regular polling interval of each ScaledObject or ScaledJob. This is the default behavior.\n* `hpa`: Sends raw metrics only when the Kubernetes metrics server explicitly requests metrics for a ScaledObject. This means metrics are sent in response to HPA queries, not on a regular schedule.\n* `pollinginterval`: Sends raw metrics only during the polling interval of each ScaledObject or ScaledJob. In this mode, metrics are pushed out at each polling cycle, regardless of HPA requests.\n* Any unknown value will default to the `all` mode.\n"
  },
  {
    "path": "content/docs/2.20/concepts/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Automatically validate resource changes to prevent misconfiguration and enforce best practices\"\nweight = 600\n+++\n\nThere are some several misconfiguration scenarios that can produce scaling problems in productive workloads, for example: in Kubernetes a single workload should never be scaled by 2 or more HPA because that will produce conflicts and unintended behaviors.\n\nSome errors with data format can be detected during the model validation, but these misconfigurations can't be detected in that step because the model is correct indeed. For trying to avoid those misconfigurations at data plane detecting them early, admission webhooks validate all the incoming (KEDA) resources (new or updated) and reject any resource that doesn't match the rules below.\n\n### Prevention Rules\n\nKEDA will block all incoming changes to `ScaledObject` that don't match these rules:\n\n- The scaled workload (`scaledobject.spec.scaleTargetRef`) is already autoscaled by another other sources (other ScaledObject or HPA).\n- CPU and/or Memory trigger are used and the scaled workload doesn't have the requests defined. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- CPU and/or Memory trigger are **the only used triggers** and the ScaledObject defines `minReplicaCount:0`. **This rule doesn't apply to all the workload types, only to `Deployment` and `StatefulSet`.**\n- In the case of multiple triggers where a `name` is **specified**, the name must be **unique** (it is not allowed to have multiple triggers with the same name)\n- The fallback feature is configured with a metrics type other than AverageValue. Fallback feature only supports AverageValue metrics type and doesn't support CPU and Memory metrics.\n\nKEDA will block all incoming changes to `TriggerAuthentication`/`ClusterTriggerAuthentication` that don't match these rules:\n\n- The specified identity ID for Azure AD Workload Identity and/or Pod Identity is empty. (Default/unset identity ID will be passed through.)\n\t> NOTE: This only applies if the `TriggerAuthentication/ClusterTriggerAuthentication` is overriding the default identityId provided to KEDA during the installation\n"
  },
  {
    "path": "content/docs/2.20/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure-workload | aws | aws-eks | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n      roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n      identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  filePath:                                                               # Optional. Define only for ClusterTriggerAuthentication; not supported for TriggerAuthentication.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    path: {relative-path-to-file}                                         # Required. Relative to --filepath-auth-root-path.\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                              # Required.\n      path: {hashicorp-vault-secret-path}                                 # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure-workload                                            # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n  awsSecretManager:\n    podIdentity:                                                          # Optional.\n      provider: aws                                                       # Required.\n    credentials:                                                          # Optional.\n      accessKey:                                                          # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_ACCESS_KEY_ID                                        # Required.\n      accessSecretKey:                                                    # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-aws-credentials}                       # Required.\n            key: AWS_SECRET_ACCESS_KEY                                    # Required.\n    region: {aws-region}                                                  # Optional.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {aws-secret-name}                                             # Required.\n      version: {aws-secret-version}                                       # Optional.\n      secretKey: {aws-secret-key}                                         # Optional.\n  gcpSecretManager:                                                       # Optional.\n    secrets:                                                              # Required.\n      - parameter: {param-name-used-for-auth}                             # Required.\n        id: {secret-manager-secret-name}                                  # Required.\n        version: {secret-manager-secret-name}                             # Optional.\n    podIdentity:                                                          # Optional.\n      provider: gcp                                                       # Required.\n    credentials:                                                          # Optional.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-gcp-iam-sa-secret}                     # Required.\n            key: {key-within-the-secret}                                  # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler. You can find the all the available authentications [here](./../authentication-providers/).\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### File(s)\n\n> **Note:** This feature requires the KEDA operator to be configured with `--filepath-auth-root-path`.\n\nYou can read authentication parameters from files mounted in the KEDA operator pod. This is useful when credentials are provided via init containers or sidecars that write to a shared volume.\n\nThe `filePath` option is only available for `ClusterTriggerAuthentication`, not for namespaced `TriggerAuthentication`.\n\n```yaml\nfilePath:                                 # Optional.\n  - parameter: apiKey                     # Required - Defined by the scale trigger\n    path: credentials/api-key             # Required - Path relative to filepath-auth-root-path\n```\n\n**Security constraints:**\n- The path is validated to ensure it resolves within the configured `--filepath-auth-root-path`\n- Access to sensitive paths like `/var/run/secrets/kubernetes.io/serviceaccount/` is blocked\n- Only `ClusterTriggerAuthentication` can use this authentication method\n\n**Assumptions:**\n- The KEDA operator must be started with `--filepath-auth-root-path=/path/to/allowed/files`\n- The credential file exists at `{filepath-auth-root-path}/{path}`\n- The file contains the raw credential value\n\n### Bound service account token(s)\n\nYou can pull one or more service account tokens into the trigger by defining the `serviceAccountName` of the Kubernetes service account.\n\n```yaml\nboundServiceAccountToken:                   # Optional.\n  - parameter: connectionString             # Required - Defined by the scale trigger\n    serviceAccountName: my-service-account  # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (the default value is `/var/run/secrets/kubernetes.io/serviceaccount/token`) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional. Default is /var/run/secrets/kubernetes.io/serviceaccount/token\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### GCP Secret Manager secret(s)\n\nYou can pull secrets from GCP Secret Manager into the trigger by using the `gcpSecretManager` key.\n\nThe `secrets` list defines the mapping between the secret and the authentication parameter.\n\nGCP IAM Service Account credentials can be used for authenticating with the Secret Manager service, which can be provided using a Kubernetes secret. Alternatively, `gcp` pod identity provider is also supported for GCP Secret Manager using `podIdentity` inside `gcpSecretManager`.\n\n```yaml\ngcpSecretManager:                                     # Optional.\n  secrets:                                            # Required.\n    - parameter: {param-name-used-for-auth}           # Required.\n      id: {secret-manager-secret-name}                # Required.\n      version: {secret-manager-secret-name}           # Optional.\n  podIdentity:                                        # Optional.\n    provider: gcp                                     # Required.\n  credentials:                                        # Optional.\n    clientSecret:                                     # Required.\n      valueFrom:                                      # Required.\n        secretKeyRef:                                 # Required.\n          name: {k8s-secret-with-gcp-iam-sa-secret}   # Required.\n          key: {key-within-the-secret}                # Required.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure-workload | aws | aws-eks | gcp               # Optional. Default: none\n  identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  roleArn: <role-arn>                                                 # Optional. Only used by aws provider.\n  identityOwner: keda|workload                                        # Optional. Only used by aws provider.\n```\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nSetting `podIdentity.azureWorkload.enabled` to `true` is required for workload identity authentication to work. For KEDA to get access to the provided client id federated credential has to be configured on the target Managed Identity / Azure AD application. Refer to these [docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html). Federated credential should use this subject (if KEDA is installed in `keda` namespace): `system:serviceaccount:keda:keda-operator`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources. In the case of override federated credentials should be configured for each of the used identities.\n\n### Aws Secret Manager(s)\n\nYou can integrate AWS Secret Manager secrets into your trigger by configuring the `awsSecretManager` key in your KEDA scaling specification.\n\nThe `podIdentity` section configures the usage of AWS pod identity with the provider set to AWS.\n\nThe `credentials` section specifies AWS credentials, including the `accessKey` and `secretAccessKey`.\n\n- **accessKey:** Configuration for the AWS access key.\n- **secretAccessKey:** Configuration for the AWS secret access key.\n\nThe `region` parameter is optional and represents the AWS region where the secret resides, defaulting to the default region if not specified.\n\nThe `secrets` list within `awsSecretManager` defines the mapping between the AWS Secret Manager secret and the authentication parameter used in your application, including the parameter name, AWS Secret Manager secret name, an optional secret key parameter, and an optional version parameter, defaulting to the latest version if unspecified.\n\n```yaml\nawsSecretManager:\n  podIdentity:                                     # Optional.\n    provider: aws                                  # Required.\n  credentials:                                     # Optional.\n    accessKey:                                     # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_ACCESS_KEY_ID                   # Required.\n    accessSecretKey:                               # Required.\n      valueFrom:                                   # Required.\n        secretKeyRef:                              # Required.\n          name: {k8s-secret-with-aws-credentials}  # Required.\n          key: AWS_SECRET_ACCESS_KEY               # Required.\n  region: {aws-region}                             # Optional.\n  secrets:                                         # Required.\n  - parameter: {param-name-used-for-auth}          # Required.\n    name: {aws-secret-name}                        # Required.\n    version: {aws-secret-version}                  # Optional.\n    secretKey: {aws-secret-key}                    # Optional.\n```\n\n#### AWS Pod Identity Webhook for AWS\n\n[**AWS IAM Roles for Service Accounts (IRSA) Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook) ([documentation](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)) allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws # Optional. Default: none\n  roleArn: <role-arn> # Optional. \n  identityOwner: keda|workload # Optional.\n```\n\n#### AWS EKS Pod Identity Webhook\n\n> [DEPRECATED: This will be removed in KEDA v3](https://github.com/kedacore/keda/discussions/5343)\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.20/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](../reference/scaledobject-spec).\n> Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.20/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\nThis page describes the deployment scaling behavior of KEDA. \n\n# Specification\n\nSee the [Scaled Object specification](../reference/scaledobject-spec.md) for details on how to set the behaviors described below.\n\n# Scaling objects\n\n## Scaling Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n## Scaling Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n# Features\n\n## Caching Metrics\n\nThis feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior such that KEDA Metrics Server tries to read metric from the cache first. This cache is updated periodically during the polling interval.\n\nEnabling [`useCachedMetrics`](../reference/scaledobject-spec/#triggers) can significantly reduce the load on the scaler service.\n\nThis feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n## Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledObject` definition:\n\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n    autoscaling.keda.sh/paused: \"true\"\n```\n\nThe presence of these annotations will pause autoscaling no matter what number of replicas is provided.\n\nThe annotation `autoscaling.keda.sh/paused` will pause scaling immediately and use the current instance count while the annotation `autoscaling.keda.sh/paused-replicas: \"<number>\"` will scale your current workload to specified amount of replicas and pause autoscaling. You can set the value of replicas for an object to be paused to any arbitrary number.\n\nTypically, either one or the other is being used given they serve a different purpose/scenario. However, if both `paused` and `paused-replicas` are set, KEDA will scale your current workload to the number specified count in `paused-replicas` and then pause autoscaling.\n\nTo unpause (reenable) autoscaling again, remove all paused annotations from the `ScaledObject` definition. If you paused with `autoscaling.keda.sh/paused`, you can unpause by setting the annotation to `false`.\n\nAdditionally, we provide the ability to temporarily pause scale in on a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-scale-in: \"true\"\n```\n\nWhen the annotation is set, KEDA will update the generated HPA to disable scale in (via setting the HPA's Scale Down Select Policy to Disabled) and if the service has scale to zero configured, will block scale to zero. When the annotation is unset, the scale down behavior on the HPA will be restored to its original configuration and, if configured, scale to zero will be unblocked. \n\nConversely, we provide the ability to temporarily pause scale out on a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-scale-out: \"true\"\n```\n\nWhen the annotation is set, KEDA will update the generated HPA to disable scale out (via setting the HPA's Scale Up Select Policy to Disabled) and if the service has scale to zero configured, will block scale from zero. When the annotation is unset, the scale up behavior on the HPA will be restored to its original configuration and, if configured, scale up from zero will be unblocked. \n\nIf you want disable scaling in both directions, we recommend you use the `autoscaling.keda.sh/paused` as that will stop the scale loop and paused queries against the ScaledObject's configured scaler.\n\n## Scaling Modifiers\n\n**Example: compose average value**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"(trig_one + trig_two)/2\"\n    target: \"2\"\n    activationTarget: \"2\"\n    metricType: \"AverageValue\"\n...\ntriggers:\n  - type: kubernetes-workload\n    name: trig_one\n    metadata:\n      podSelector: 'pod=workload-test'\n  - type: metrics-api\n    name: trig_two\n    metadata:\n      url: \"https://mockbin.org/bin/336a8d99-9e09-4f1f-979d-851a6d1b1423\"\n      valueLocation: \"tasks\"\n```\n\nFormula composes 2 given metrics from 2 triggers `kubernetes-workload` named `trig_one` and `metrics-api` named `trig_two` together as an average value and returns one final metric which is used to make autoscaling decisions on.\n\n**Example: activationTarget**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    activationTarget: \"2\"\n```\n\nIf the calculated value is <=2, the ScaledObject is not `Active` and it'll scale to 0 if it's allowed.\n\n**Example: ternary operator**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one > 2 ? trig_one + trig_two : 1\"\n```\n\nIf metric value of trigger `trig_one` is more than 2, then return `trig_one` + `trig_two` otherwise return 1.\n\n**Example: count function**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"count([trig_one,trig_two,trig_three],{#>1}) > 1 ? 5 : 0\"\n```\n\nIf at least 2 metrics (from the list `trig_one`,`trig_two`,`trig_three`) have value of more than 1, then return 5, otherwise return 0\n\n**Example: nested conditions and operators**\n\n```yaml\nadvanced:\n  scalingModifiers:\n    formula: \"trig_one < 2 ? trig_one+trig_two >= 2 ? 5 : 10 : 0\"\n```\n\nConditions can be used within another condition as well.\nIf value of `trig_one` is less than 2 AND `trig_one`+`trig_two` is at least 2 then return 5, if only the first is true return 10, if the first condition is false then return 0.\n\nComplete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean). All formulas are internally wrapped with float cast.\n\n## Activating and Scaling thresholds\n\nKEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Forcing Activation\n\nWe provide the ability to temporarily force the activation of a scale target:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/force-activation: \"true\"\n```\n\nWhen the annotation is set, KEDA will treat all configured scalers as active. If the scalers were previously not active, KEDA will scale the service up from 0.\n\nWhen the annotation is subsequently unset, the state of the scaler activation will revert to being computed from the state of the scaler metrics.\n\n## Transferring ownership of an existing HPA\n\nIf your environment already operates using kubernetes HPA, you can transfer the ownership of this resource to a new ScaledObject:\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"\nspec:\n   advanced:\n      horizontalPodAutoscalerConfig:\n        name: {name-of-hpa-resource}\n```\n\n> ⚠️ **NOTE:** You need to specify a custom HPA name in your ScaledObject matching the existing HPA name you want it to manage.\n\n## Disabling validations on an existing HPA\n\nYou are allowed to disable admission webhooks validations with the following snippet. It grants you better flexibility but also brings vulnerabilities. Do it **at your own risk**.\n\n```yaml\nmetadata:\n  annotations:\n    validations.keda.sh/hpa-ownership: \"true\"\n```\n\n### Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n#### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n#### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](./scaling-jobs).\n\n## Excluding labels from being propagated to the HPA\n\nYou can exclude specific labels from being propagated to the generated HPA object by using the `scaledobject.keda.sh/hpa-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded.\n\n```yaml\nmetadata:\n  annotations:\n    scaledobject.keda.sh/hpa-excluded-labels: \"foo.bar/environment,foo.bar/version\"\n  labels:\n    team: backend\n    foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5\n    foo.bar/version: \"1\"\n"
  },
  {
    "path": "content/docs/2.20/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\nThis page describes the job scaling behavior of KEDA. See the [Scaled Job specification](../reference/scaledjob-spec.md) for details on how to set the behaviors described below.\n\n\n# Overview\n\nAs an alternate to [scaling event-driven code as deployments](./scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n\n# Pausing autoscaling\n\nIt can be useful to instruct KEDA to pause the autoscaling of objects, to do to cluster maintenance or to avoid resource starvation by removing non-mission-critical workloads.\n\nThis is preferable to deleting the resource because it removes the instances it is running from operation without touching the applications themselves. When ready, you can then reenable scaling.\n\nYou can pause autoscaling by adding this annotation to your `ScaledJob` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: true\n```\n\nTo reenable autoscaling, remove the annotation from the `ScaledJob` definition or set the value to `false`.\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused: false\n```\n\n\n## Example\n\nAn example configuration for autoscaling jobs using a RabbitMQ scaler is given below. \n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n# Excluding labels from being propagated to the Job\n\nYou can exclude specific labels from being propagated to the generated Job object by using the `scaledjob.keda.sh/job-excluded-labels` annotation. This annotation accepts a comma-separated list of label keys that should be excluded.\n\n```yaml\nmetadata:\n  annotations:\n    scaledjob.keda.sh/job-excluded-labels: \"foo.bar/environment,foo.bar/version\"\n  labels:\n    team: backend\n    foo.bar/environment: bf5011472247b67cce3ee7b24c9a08c5\n    foo.bar/version: \"1\"\n"
  },
  {
    "path": "content/docs/2.20/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.20/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nKEDA offers multiple installation methods, each with unique benefits to suit various environments and needs. If you’re looking for flexibility and customization, deploying with **Helm** is ideal; it integrates well with environments that have established Helm workflows and allows easy configuration adjustments. For a straightforward setup, installing through **Operator Hub** provides a quick, one-click deployment with automatic updates, which is great for users seeking minimal customization.\n\nUsing **YAML files** offers the most control over your setup, making it perfect for environments requiring strict configurations or where Helm and Operator Hub are not options. Finally, deploying KEDA on **MicroK8s** is excellent for local or development testing, providing a lightweight Kubernetes environment that’s fast to set up without the commitment of a full cluster.\n\nEach method balances convenience, control, and compatibility differently: Helm is best for extensive customization, Operator Hub for simplicity, YAML files for precise configuration, and MicroK8s for local experimentation. Select the option that aligns with your deployment requirements and environment.\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.30 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Prerequisites\n\nTo deploy KEDA using Helm, make sure Helm is installed and configured on your system. Helm is a package manager for Kubernetes that simplifies the deployment process by handling complex configurations and templating, which is particularly useful for managing multiple instances or custom settings. It’s recommended to use the latest version of Helm to ensure compatibility with KEDA and access to the newest features.\n\nIf you’re new to Helm, start by familiarizing yourself with basic Helm commands ([`helm install`](https://helm.sh/docs/helm/helm_install/)`, helm upgrade, helm repo add`). Ensure that you have permissions to install charts on your Kubernetes cluster, as some environments may restrict access. A properly configured Helm setup will allow you to deploy KEDA quickly and make adjustments to configurations with ease.\n\n### Installing\n\n1. To deploy KEDA using Helm, first add the official KEDA Helm repository:\n\n    ```sh\n   helm repo add kedacore https://kedacore.github.io/charts  \n   helm repo update\n    ```\n\n2. Install `keda` by running:\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n    This command installs KEDA in a dedicated namespace (keda). You can customize the installation by passing additional configuration values with `--set`, allowing you to adjust parameters like replica counts, scaling metrics, or logging levels. Once installed, verify the deployment by checking the KEDA namespace for running pods:\n\n    ```sh\n    kubectl get pods -n keda\n    ```\n\nTo deploy KEDA's Custom Resource Definitions (CRDs) separately from the Helm chart, follow these steps:\n\n1. **Download the CRD YAML File**: Visit the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases) and locate the `keda-2.xx.x-crds.yaml` file corresponding to your desired version.\n2. **Apply the CRDs to Your Cluster**: Use `kubectl` to apply the CRD definitions:\n\n    ```sh\n    kubectl apply -f keda-2.xx.x-crds.yaml\n    ```\n\n    Replace `2.xx.x` with the specific version number you downloaded.\n\nBy deploying the CRDs separately, you can manage them independently of the Helm chart, providing flexibility in your deployment process.\n> 💡 **NOTE:** When upgrading to KEDA version 2.2.1 or later, it's important to address potential issues with CRDs. Starting with v2.2.1, KEDA's Helm chart manages CRDs automatically, which can lead to upgrade failures if you previously installed KEDA using an earlier version. To prevent errors during the upgrade process, such as conflicts or failed deployments, consult KEDA's [troubleshooting guide](https://keda.sh/docs/2.0/troubleshooting/) for detailed instructions on resolving CRD-related issues.\n\nDeploying KEDA with Helm is straightforward and allows easy updates and configuration adjustments, making it a flexible choice for most environments.\n\n### Uninstalling\n\nTo uninstall KEDA, use the following Helm command:\n\n```sh\nhelm uninstall keda –namespace keda\n```\n\nThis command removes KEDA from your cluster while retaining your configuration files in case you need to reinstall later. If you also want to delete the keda namespace, run:\n\n```sh\nkubectl delete namespace keda\n```\n\nUninstalling with Helm is efficient and keeps your cluster clean, especially if you're testing configurations or upgrading to a new KEDA version.\n\nYou can remove finalizers with the following command:\n\n```sh\nkubectl patch scaledobject <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\nkubectl patch scaledjob <resource-name> -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\n```\n\nReplace \\<*resource-name*\\> with the specific name of each resource. Removing finalizers ensures that these resources are fully removed, preventing any unintended orphaned resources in your cluster.\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Prerequisites\n\nBefore deploying KEDA through Operator Hub, ensure you have access to a Kubernetes marketplace that supports Operator Hub (for example, [OpenShift](https://docs.redhat.com/en) or an [Operator Lifecycle Manager](https://olm.operatorframework.io/docs/) (OLM)-enabled cluster). You'll also need the appropriate permissions to install operators in your cluster, as some environments may restrict access.\n\nIf you're using OpenShift, you can access Operator Hub directly through the OpenShift Console. For other Kubernetes distributions, verify that the OLM is installed, as it manages the installation and lifecycle of operators from Operator Hub. Ensuring these prerequisites are met will allow for a smooth installation of KEDA from Operator Hub.\n\n### Installing\n\nTo deploy KEDA through Operator Hub, start by navigating to your cluster's Operator Hub interface. If you're using OpenShift, access Operator Hub directly from the OpenShift Console. For other Kubernetes environments, ensure the **Operator Lifecycle Manager (OLM)** is installed.\n\nSearch for \"KEDA\" in Operator Hub, select the KEDA Operator, and click **Install**. Choose your preferred installation options, such as the target namespace, and confirm the installation. Once KEDA is installed, verify the deployment by checking that the KEDA Operator pod is running in the designated namespace.\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\nUsing Operator Hub simplifies KEDA deployment, offering easy setup and automated lifecycle management within your Kubernetes environment.\n\n> 💡 **NOTE:** For more details on deploying KEDA with the Operator Hub installation method, refer to the official repository:\n> \n> [KEDA Operator Hub Repository](https://github.com/kedacore/keda-olm-operator)\n> \n> This repository provides additional guidance, configuration options, and troubleshooting tips for installing KEDA via Operator Hub in various Kubernetes environments.\n> \n> For beginners exploring the [`keda-olm-operator repository`](https://github.com/kedacore/keda-olm-operator), the following files and directories are particularly helpful:\n>\n> \\- **`README.md`:** This file provides an overview of the project, including installation instructions and usage examples. It's a great starting point to understand the purpose and functionality of the operator.\n> \n> \\- **`config/samples/`**: This directory contains sample YAML files that demonstrate how to configure KEDA resources. Reviewing these samples can help you learn how to define and apply custom resources in your Kubernetes cluster.\n> \n> \\- **`Makefile`**: The `Makefile` includes commands for building and deploying the operator. Examining this file can give you insights into the development and deployment processes used in the project.\n\n### Uninstalling\n\nTo uninstall KEDA, go to your cluster’s Operator Hub interface and locate the **Installed Operators** section. Find the KEDA Operator in the list, select it, and choose **Uninstall**. Confirm the uninstallation to remove the operator from your cluster.\n\nIf you deployed KEDA in a specific namespace, you may also want to delete that namespace to fully clean up any remaining resources. Uninstalling with Operator Hub keeps your cluster organized by removing all KEDA-related components with a few clicks.\n\n## Deploying KEDA using the YAML files {#yaml}\n\n### Prerequisites\n\nBefore deploying KEDA with YAML files, ensure you have `kubectl` installed and configured to interact with your Kubernetes cluster. You’ll also need the KEDA YAML manifests, which you can download from the [KEDA GitHub releases page](https://github.com/kedacore/keda/releases). This method provides full control over configuration and is ideal if you need a highly customized setup or don’t have access to Helm or Operator Hub. Make sure you have the appropriate permissions to apply these configurations in your cluster.\n\n### Installing\n\nOnce the KEDA YAML manifests are downloaded, apply the files to your cluster with the following command:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml\n# Without admission webhooks\nkubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0-core.yaml\n```\n\nAlternatively you can download the file and deploy it from the local path:\n\n```sh\n# Including admission webhooks\nkubectl apply --server-side -f keda-2.20.0.yaml\n# Without admission webhooks\nkubectl apply --server-side -f keda-2.20.0-core.yaml\n```\n\nThe `--server-side` flag allows Kubernetes to manage complex resources, like CRDs and admission webhooks, directly on the server. This approach reduces conflicts and ensures configurations are efficiently merged. For more information, see [this issue](https://github.com/kedacore/keda/issues/4740).\n\n> 💡 **NOTE:**  If you prefer working directly from the [KEDA GitHub repository](https://github.com/kedacore/keda), you can find the necessary YAML files in the `/config` directory. Cloning the repository allows you to manage and deploy KEDA configurations locally:\n>\n> ```sh\n> git clone https://github.com/kedacore/keda && cd keda\n> \n> VERSION=2.20.0 make deploy\n> ```\n>\n> This approach gives you full access to KEDA’s configuration files, allowing you to explore, modify, or tailor the YAML manifests before deploying. Using make deploy with the specified version will install KEDA directly from your local setup, offering flexibility for customization.\n\nAfter applying the YAML, verify the deployment by checking the KEDA namespace:\n\n```sh\nkubectl get pods -n keda\n```\n\nDeploying KEDA this way provides control over configuration while leveraging server-side merging for smoother updates.\n\n### Uninstalling\n\nIf you installed KEDA using the released YAML files, you can uninstall it by running the following commands:\n\n```sh\n# Including admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0.yaml\n# Without admission webhooks\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.20.0/keda-2.20.0-core.yaml\n```\n\nIf you downloaded the files locally, uninstall with:\n\n```sh\n# Including admission webhooks\nkubectl delete -f keda-2.20.0.yaml\n# Without admission webhooks\nkubectl delete -f keda-2.20.0-core.yaml\n```\n\nFor users who cloned the KEDA GitHub repository, navigate to the cloned directory and use:\n\n```sh\nVERSION=2.20.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Prerequisites\n\nBefore deploying KEDA on [**MicroK8s**](https://microk8s.io/), ensure that you have MicroK8s installed and running on your local machine. MicroK8s is a lightweight Kubernetes distribution, ideal for testing and local development. You’ll need `kubectl` configured to interact with your MicroK8s cluster, which is typically included with MicroK8s but may require enabling (`microk8s kubectl`).\n\nAdditionally, confirm that your MicroK8s setup includes the **Helm 3** and **DNS** add-ons:\n\n* **Helm 3**: KEDA utilizes Helm charts for deployment, making Helm 3 essential for managing KEDA's installation and configuration.\n* **DNS**: Kubernetes services rely on DNS for internal communication. Enabling the DNS add-on ensures that KEDA components can resolve service names within the cluster, facilitating proper operation.\n\n### Installing\n\nTo install KEDA on MicroK8s, start by enabling necessary add-ons and then deploy KEDA using the Helm 3 add-on.\n\n1. Enable Helm and DNS Add-ons (if not already enabled):\n\n   ```sh\n   microk8s enable dns helm3use\n   ```\n\n2. Add the KEDA Helm Repository:\n\n   ```sh\n   microk8s helm3 repo add kedacore https://kedacore.github.io/charts\n   \n   microk8s helm3 repo update\n   ```\n\n3. Install KEDA Using Helm.\n\n   Deploy KEDA into your MicroK8s cluster by running:\n\n   ```sh\n   microk8s helm3 install keda kedacore/keda --namespace keda --create-namespace\n   ```\n\n4. Verify the Installation.\n\n   Check that KEDA is running by listing the pods in the keda namespace:\n\n   ```sh\n   microk8s kubectl get pods -n keda\n   ```\n\nThis approach allows you to quickly set up KEDA on MicroK8s, providing a streamlined environment for local testing and development.\n\n### Uninstalling\n\nTo uninstall KEDA from your MicroK8s environment, disable the KEDA add-on:\n\n```sh\nmicrok8s disable keda\n```\n\nThis command removes KEDA and its associated components from your cluster, ensuring a clean uninstallation.\nIf you deployed KEDA using Helm, uninstall it with:\n\n```sh\nmicrok8s helm3 uninstall keda --namespace keda\n```\n\nAfter running these commands, KEDA will be fully removed from your MicroK8s setup.\n\n## Getting Started with KEDA: A Simple Example\n\nTo help you begin with KEDA, we'll walk through a straightforward example that demonstrates its event-driven scaling capabilities. This \"Hello KEDA\" exercise will guide you through setting up a basic application that scales based on external events, providing a hands-on introduction to KEDA's functionality.\n\nBefore starting, ensure you have the following:\n\n* **Kubernetes Cluster**: A running Kubernetes cluster. You can use Minikube, Kind, or any cloud-based Kubernetes service.\n* **kubectl**: The Kubernetes command-line tool, configured to interact with your cluster.\n* **KEDA Installed**: KEDA should be installed in your cluster.\n\n### Step 1: Deploy a Sample Application\n\nWe'll deploy a simple application that responds to HTTP requests. For this example, we'll use a basic Python HTTP server.\n\n1. **Create a Deployment Manifest**: Save the following YAML as `deployment.yaml`:\n\n   ```yaml\n   apiVersion: apps/v1\n   kind: Deployment\n   metadata:\n      name: http-app\n   spec:\n      replicas: 1\n      selector:\n         matchLabels:\n            app: http-app\n      template:\n         metadata:\n            labels:\n               app: http-app\n         spec:\n            containers:\n            - name: http-app\n              image: hashicorp/http-echo\n              args:\n                 - \"-text=Hello, KEDA!\"\n              ports:\n                 - containerPort: 5678\n      ```\n\n2. **Apply the Deployment**: Run the following command to create the deployment:\n\n   ```sh\n   kubectl apply -f deployment.yaml\n   ```\n\n### Step 2: Expose the Application\n\nTo access the application, we'll create a Service.\n\n1. **Create a Service Manifest**: Save the following YAML as `service.yaml`:\n\n   ```yaml\n   apiVersion: v1\n   kind: Service\n   metadata:\n      name: http-app-service\n   spec:\n      selector:\n         app: http-app\n      ports:\n         - protocol: TCP\n           port: 80\n           targetPort: 5678\n      type: LoadBalancer\n   ```\n\n2. **Apply the Service**: Run the following command to create the service:\n\n   ```sh\n   kubectl apply -f service.yaml\n   ```\n\n3. **Retrieve the External IP**: After a few moments, retrieve the external IP address:\n\n   ```sh\n   kubectl get service http-app-service\n   ```\n\n### Step 3: Create a ScaledObject\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\n\n1. **Create a ScaledObject Manifest**: Save the following YAML as `scaledobject.yaml`:\n\n   ```yaml\n   apiVersion: keda.sh/v1alpha1\n   kind: ScaledObject\n   metadata:\n      name: http-app-scaledobject\n   spec:\n      scaleTargetRef:\n         name: http-app\n      minReplicaCount: 1\n      maxReplicaCount: 10\n      triggers:\n         - type: prometheus\n           metadata:\n              serverAddress: http://prometheus-server.default.svc.cluster.local:9090\n              threshold: '5'\n              query: sum(rate(http_requests_total[1m])) \n   ```\n\n   > 💡 **NOTE:** This example assumes you have Prometheus installed in your cluster and scraping metrics from your application. Adjust the `serverAddress` and `query` as needed.\n2. **Apply the ScaledObject**: Run the following command to create the ScaledObject:\n\n   ```sh\n   kubectl apply -f scaledobject.yaml   \n   ```\n\n### Step 4: Test the Scaling Behavior\n\nWe'll create a `ScaledObject` to enable KEDA to scale our deployment based on HTTP request rates.\nTo observe KEDA's scaling in action:\n\n1. **Generate Load**: Use a tool like curl or hey to send multiple requests to your application's external IP:\n\n   ```sh\n   hey -z 1m -c 10 http://<EXTERNAL-IP>\n   ```\n\n   Replace `<EXTERNAL-IP>` with the external IP address obtained earlier.\n2. **Monitor Scaling:** Run the following command to watch the scaling behavior:\n\n   ```sh\n   kubectl get pods -w\n   ```\n\n   You should see the number of pods increase as the load increases and decrease when the load subsides.\n\n### Cleanup\n\nAfter completing the exercise, clean up the resources:\n\n   ```sh\n   kubectl delete -f scaledobject.yaml\n   kubectl delete -f service.yaml\n   kubectl delete -f deployment.yaml\n   ```\n\nThis example provides a hands-on introduction to KEDA's event-driven scaling capabilities. By following these steps, you can see how KEDA integrates with Kubernetes to scale applications based on external events.\n"
  },
  {
    "path": "content/docs/2.20/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.20/integrations/istio-integration.md",
    "content": "+++\ntitle = \"KEDA Integration with Istio\"\ndescription = \"Guidance for running KEDA along with Istio in your cluster\"\navailability = \"v2.14+\"\nproject = \"Istio\"\n+++\n\n## Overview\n\nIntegrating KEDA with Istio can present challenges, particularly in environments with enforced mTLS. This document provides guidance on how to configure KEDA to work within an Istio service mesh without disabling Istio sidecar injection. This solution allows KEDA components to communicate securely and effectively while maintaining compliance with security requirements.\n\nThis can be considered as workaround, however it's perfectly valid from the security standpoint. \nKeda is still using own mTLS certificates for secure communication between it's components and at the same time it's able to communicate with Istio Mesh services (like Prometheus) through Istio sidecar proxies.\n\n## Background\n\nIn some scenarios, users might face issues with KEDA components failing discovery checks when Istio sidecar injection is enabled. The current [troubleshooting guide](../../../troubleshooting/istio-keda-faileddiscoverycheck) suggests disabling Istio sidecar injection in the KEDA namespace. However, if this is not feasible due to security policies, the following workaround can be applied.\n\n\n### Requirements\n\n- Istio version >= 1.18.*\n- Kubernetes cluster with KEDA installed\n\n### Example configuration\n\n`values.yaml` fragment for the [helm chart](https://github.com/kedacore/charts/blob/main/keda/values.yaml)\n```\n... \n\npodAnnotations:\n  # -- Pod annotations for KEDA operator\n  keda:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9666\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9443,6443\"\n  # -- Pod annotations for KEDA Metrics Adapter\n  metricsAdapter:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"6443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,9443\"\n  # -- Pod annotations for KEDA Admission webhooks\n  webhooks:\n    traffic.sidecar.istio.io/excludeInboundPorts: \"9443\"\n    traffic.sidecar.istio.io/excludeOutboundPorts: \"9666,6443\"\n\n...\n\n```\n\n*Check your respective ports set correctly for each component.*\n\n### Applying the Annotations\n- Annotate the KEDA Components: Update the deployment manifests for the KEDA operator, Metrics Adapter, and Admission Webhooks to include the specified pod annotations.\n- Deploy Updated Manifests: Apply the updated manifests to your Kubernetes cluster.\n- Verify Communication: Ensure that KEDA components can communicate internally and with external mesh services without failing discovery checks.\n\n\n### References\nFor more information on the annotations used, refer to the Istio documentation on traffic management.\nExisting troubleshooting guide for KEDA with Istio.\n\n### Conclusion\nBy applying these annotations, you can ensure that KEDA integrates seamlessly with Istio while adhering to security requirements. This configuration allows KEDA to maintain internal mTLS communication and interact properly with other mesh services.\n\nIf you encounter any issues or have further questions, please refer to the KEDA and Istio documentation or reach out to the community for support.\n"
  },
  {
    "path": "content/docs/2.20/integrations/opentelemetry.md",
    "content": "+++\ntitle= \"Integrate with OpenTelemetry Collector (Experimental)\"\ndescription= \"Detail of integrating OpenTelemetry Collector in KEDA\"\navailability = \"v2.12+\"\nproject = \"OpenTelemetry\"\n+++\n\n## Push Metrics to OpenTelemetry Collector (Experimental)\n\n### Operator\n\nThe KEDA Operator supports outputting metrics to the OpenTelemetry collector. The parameter `--enable-opentelemetry-metrics=true` needs to be set. KEDA will push metrics to the OpenTelemetry collector specified by the `OTEL_EXPORTER_OTLP_ENDPOINT` environment variable. `OTEL_EXPORTER_OTLP_PROTOCOL` will also be used to choose HTTP or GRPC client. Other environment variables in OpenTelemetry are also supported (https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/). Here is an example configuration of the operator: \n```\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  ...\n      containers:\n        - name: keda-operator\n          image: ghcr.io/kedacore/keda:latest\n          command:\n            - /keda\n          args:\n            --enable-opentelemetry-metrics=true\n            ...\n          ...\n          env:\n            - name: OTEL_EXPORTER_OTLP_ENDPOINT\n              value: \"http://opentelemetry-collector.default.svc.cluster.local:4318\"\n```\nThe following metrics are being gathered:\n\n| Metric | Description |\n| ------ | ----------- |\n| `keda.build.info` | Info metric, with static information about KEDA build like: version, git commit and Golang runtime info. |\n| `keda.scaler.active` | This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0). |\n| `keda.scaled.object.paused` | This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0). |\n| `keda.scaler.metrics.value` | The current value for each scaler's metric that would be used by the HPA in computing the target average. |\n| `keda.scaler.metrics.latency.seconds` | The latency of retrieving current metric from each scaler. |\n| `keda.scaler.errors` | The number of errors that have occurred for each scaler. |\n| `keda.scaler.errors.total` | The total number of errors encountered for all scalers. |\n| `keda.scaler.empty.upstream.responses` | The number of times a scaler query returned an empty result from its upstream source, such as a Prometheus query returning no results. |\n| `keda.scaled.object.errors` | The number of errors that have occurred for each ScaledObject. |\n| `keda.scaled.job.errors` | The number of errors that have occurred for each ScaledJob. |\n| `keda.resource.registered.count` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.registered.count` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency.seconds` | Total deviation between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n| `keda.cloudeventsource.events.emitted.count` | Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state. |\n| `keda.cloudeventsource.events.queued` | The number of events that are in the emitting queue. |\n\n#### Deprecated metrics\n\nThe following metrics are exposed as well, but are deprecated and will be removed in KEDA v2.16.\n\n| `keda.scaler.metrics.latency` | The latency of retrieving current metric from each scaler. |\n| `keda.resource.totals` | Total number of KEDA custom resources per namespace for each custom resource type (CRD). |\n| `keda.trigger.totals` | Total number of triggers per trigger type. |\n| `keda.internal.scale.loop.latency` | Total deviation (in milliseconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric. |\n"
  },
  {
    "path": "content/docs/2.20/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_build_info` - Info metric, with static information about KEDA build like: version, git commit and Golang runtime info.\n- `keda_scaler_active` - This metric marks whether the particular scaler is active (value == 1) or in-active (value == 0).\n- `keda_scaled_object_paused` - This metric indicates whether a ScaledObject is paused (value == 1) or un-paused (value == 0).\n- `keda_scaler_metrics_value` - The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_metrics_latency_seconds` - The latency of retrieving current metric from each scaler.\n- `keda_scaler_detail_errors_total` - The number of errors encountered for each scaler.\n- `keda_scaler_empty_upstream_responses_total` - The number of times a scaler returned an empty response from its upstream source (e.g. a Prometheus query returning no results).\n- `keda_scaled_object_errors_total` - The number of errors that have occurred for each ScaledObject.\n- `keda_scaled_job_errors_total` - The number of errors that have occurred for each ScaledJob.\n- `keda_resource_registered_total` - Total number of KEDA custom resources per namespace for each custom resource type (CRD) handled by the operator.\n- `keda_trigger_registered_total` - Total number of triggers per trigger type handled by the operator.\n- `keda_internal_scale_loop_latency_seconds` - Total deviation (in seconds) between the expected execution time and the actual execution time for the scaling loop. This latency could be produced due to accumulated scalers latencies or high load. This is an internal metric.\n- `keda_cloudeventsource_events_emitted_total` - Measured emitted cloudevents with destination of this emitted event (eventsink) and emitted state.\n- `keda_cloudeventsource_events_queued` - The number of events that are in the emitting queue.\n- `keda_internal_metricsservice_grpc_server_started_total` - Total number of RPCs started on the server.\n- `keda_internal_metricsservice_grpc_server_handled_total` - Total number of RPCs completed on the server, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_server_msg_received_total` - Total number of RPC stream messages received on the server.\n- `keda_internal_metricsservice_grpc_server_msg_sent_total` - Total number of gRPC stream messages sent by the server.\n- `keda_internal_metricsservice_grpc_server_handling_seconds` - Histogram of response latency (seconds) of gRPC that had been application-level handled by the server.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n> Note: When you deploy the KEDA Operator without any scalers deployed, the only metric you will see is `keda_build_info`. As you deploy scalers, you will start to see some of the metrics listed above but it is dependant on the types of scalers you have deployed.\n\n### Admission Webhooks\n\nThe KEDA Webhooks expose Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_webhook_scaled_object_validation_total`- The current value for scaled object validations.\n- `keda_webhook_scaled_object_validation_errors` - The number of validation errors.\n\n### Metrics Server\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_internal_metricsservice_grpc_client_started_total` - Total number of RPCs started on the client.\n- `keda_internal_metricsservice_grpc_client_handled_total` - Total number of RPCs completed by the client, regardless of success or failure.\n- `keda_internal_metricsservice_grpc_client_msg_received_total` - Total number of RPC stream messages received by the client.\n- `keda_internal_metricsservice_grpc_client_msg_sent_total` - Total number of gRPC stream messages sent by the client.\n- `keda_internal_metricsservice_grpc_client_handling_seconds` - Histogram of response latency (seconds) of the gRPC until it is finished by the application.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n- Metrics exposed (prepended with `apiserver_`) by [Kubernetes API Server](https://kubernetes.io/docs/reference/instrumentation/metrics/)\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaledJob\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.20/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#keda-custom-resources-crds).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](./reference/scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](./reference/scaledjob-spec/)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.20/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance and requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance and requirements around various areas to operate KEDA:\n\n- [Admission Webhooks](./admission-webhooks)\n- [Cluster](./cluster)\n- [Kubernetes Events](../reference/events)\n- [KEDA Metrics Server](./metrics-server)\n- [Security](./security)\n"
  },
  {
    "path": "content/docs/2.20/operate/admission-webhooks.md",
    "content": "+++\ntitle = \"Admission Webhooks\"\ndescription = \"Admission webhooks configurations guidance\"\nweight = 100\n+++\n\n## Validation Enforcement\n\nBy default, the admission webhooks are registered with `failurePolicy: Ignore`, this won't block the resources creation/update when the admission controller is not available. To ensure that the validation is always required and perform validation, setting `failurePolicy` to `Fail` is required.\n\nIn particular, the admission webhooks for HPA ownership validation can be skipped by setting the annotation `validations.keda.sh/hpa-ownership` to `\"false\"`. Be cautious when doing so as it exposes the system to potential risks.\n\n### Cache Miss with Fallback to Direct Client for ScaledObject\n\nWhen validation enforcement is enabled, it's possible to run into a race condition when `ScaledObject` is part of the same deployment artifact as the `scaleTargetRef` (see also issue: [#5973](https://github.com/kedacore/keda/issues/5973)). For this purpose it's possible to configure additional argument for the webhook `Deployment`:\n```\n--cache-miss-to-direct-client=true\n```\nThis will ensure that if getting the `scaleTargetRef` from the cached client returns `IsNotFound` error, the webhook will attempt to get the object directly from Kubernetes API.\n\n\n## Custom Validations using Kubernetes ValidatingAdmissionPolicy\n\n> ⚠️ FEATURE STATE: Kubernetes v1.30 [stable]\n\nKubernetes `ValidatingAdmissionPolicy` allows you to create custom validation policies using the [Common Expression Language (CEL)](https://cel.dev). This provides a declarative way to define and enforce validation rules directly within the cluster, helping ensure resource configurations meet your specified requirements. For more details, refer to the Kubernetes `ValidatingAdmissionPolicy` [documentation](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).\n\nHere is an example of a `ValidatingAdmissionPolicy` and its corresponding `ValidatingAdmissionPolicyBinding` to fail/deny `ScaledObject`s with more than 10 replicas in the `default` namespace (i.e., limiting the maximum number of pod replicas to 10):\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-keda-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"keda.sh\"]\n      apiVersions: [\"v1alpha1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"scaledobjects\"]\n  validations:\n    - expression: \"object.spec.maxReplicaCount <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-keda-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-keda-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```\n\nSince KEDA manages the `HorizontalPodAutoscaler` (HPA) behind the scenes, here is a complementary configuration to deny scaling for `HPA`, `Deployments`, and `ReplicaSets` with more than 10 replicas:\n\n```yaml\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-apps-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"apps\"]\n      apiVersions: [\"v1\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"deployments\", \"replicasets\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicy\nmetadata:\n  name: \"limit-hpa-replicas.example.com\"\nspec:\n  failurePolicy: Fail\n  matchConstraints:\n    resourceRules:\n    - apiGroups:   [\"autoscaling\"]\n      apiVersions: [\"v2\"]\n      operations:  [\"CREATE\", \"UPDATE\"]\n      resources:   [\"horizontalpodautoscalers\"]\n  validations:\n    - expression: \"object.spec.replicas <= 10\"\n      message: \"The maximum allowed number of pod replicas is 10.\"\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-apps-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-apps-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n---\napiVersion: admissionregistration.k8s.io/v1\nkind: ValidatingAdmissionPolicyBinding\nmetadata:\n  name: \"limit-hpa-replicas-binding.example.com\"\nspec:\n  policyName: \"limit-hpa-replicas.example.com\"\n  validationActions: [Deny]\n  matchResources:\n    namespaceSelector:\n      matchLabels:\n        kubernetes.io/metadata.name: default\n```"
  },
  {
    "path": "content/docs/2.20/operate/cloud-events.md",
    "content": "+++\ntitle = \"CloudEvent Support\"\ndescription = \"Experimental support for cloud events\"\nweight = 100\n+++\n\n## Subscribing to events with `CloudEventSource`\n`CloudEventSource` resource can be used in KEDA for subscribing to events that are emitted to the user's defined CloudEvent sink.\n\n> 📝 When a CloudEventSource resource is created, KEDA continues to emit Kubernetes Events and will additionally emit CloudEvents for the supported event types listed in this document.\n\nHere is a the schema of the `CloudEventSource` CRD:\n\n```yaml\napiVersion: eventing.keda.sh/v1alpha1\nkind: CloudEventSource\nmetadata:\n  name: {cloud-event-name}\nspec:\n  clusterName: {cluster-name} #Optional. Will be used in the source/subject to specify where the event comes from. The default value is 'kubernetes-default' and it can also be set during the installation of KEDA with --k8sClusterName. This one will overwrite others if set.\n  authenticationRef: \n    name: {trigger-authentication-name} #Optional. Used to reference a `TriggerAuthentication` for authentication. \n    kind: TriggerAuthentication # Optional. Used to choose the authentication scopes. https://keda.sh/docs/latest/concepts/authentication/#authentication-scopes-namespace-vs-cluster\n  destination:\n    http:\n      uri: http://foo.bar\n    azureEventGridTopic:\n      endpoint: https://my-topic.eastus-1.eventgrid.azure.net/api/events\n\n  eventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n    includedEventTypes: #Optional. Only events in this section will be emitted.\n    - keda.scaledobject.failed.v1\n    excludedEventTypes: #Optional. Events in this section will not be emitted.       \n    - keda.scaledobject.ready.v1\n```\n\nIn general, an event emitted by KEDA would fundamentally come down to the following structure:\n```json\n{\n    \"specversion\" : \"1.0\",\n    \"type\" : \"com.cloudeventsource.keda\",\n    \"source\" : \"/{cluster-name}/{keda-namespace}/keda\",\n    \"subject\" : \"/{cluster-name}/{namespace}/{object-type}/{object-name}\",\n    \"id\" : \"<guid>\",\n    \"time\" : \"2018-04-05T17:31:00Z\",\n    \"datacontenttype\" : \"application/json\",\n    \"data\" : {\n      \"reason\":\"<event-reason>\",\n      \"message\":\"<event-message>\"\n   }\n}\n```\n\n## Event Sinks\n\nThere will be multiple types of destination to emit KEDA events to.\n\nHere is an overview of the supported destinations:\n\n- [HTTP endpoint](#http-endpoint).\n- [Azure Event Grid endpoint](#azure-event-grid).\n\n### HTTP endpoint\n```yaml\n  destination:\n    http:\n      uri: http://foo.bar  #An http endpoint that can receive cloudevent\n```\n\n### Azure Event Grid\n\n```yaml\n  destination:\n    azureEventGrid:\n      endpoint: foo.bar #endpoint from AzureEventGrid Topic\n```\n\nAuthentication information must be provided by using `authenticationRef` which allows you to provide the access key or managed identity for Azure Event Grid authentication by providing a `TriggerAuthentication`.\n\nHere is an overview of the supported authentication types:\n\n#### Connection String Authentication\n\n- `accessKey` - Access key string for the Azure Event Grid connection auth.\n\n#### Pod identity based authentication\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\n## Event Filter\n\nYou can include filter(s) to define what event types you are interested in, or want to ignore. This is done by using `includedEventTypes` or `excludedEventTypes` respectively for a given sink.\n\n```yaml\neventSubscription: #Optional. Submit included/excluded event types will filter events when emitting events. \n  includedEventTypes: #Optional. Only events in this section will be emitted.\n  - keda.scaledobject.failed.v1\n  excludedEventTypes: #Optional. Events in this section will not be emitted.       \n  - keda.scaledobject.ready.v1\n```\n\n## Supported Event List\n| Event Type                                 | Scenario Description                                                                                                          |\n|--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|\n| `keda.scaledobject.ready.v1`               | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False`   |\n| `keda.scaledobject.failed.v1`              | If the check validation for a ScaledObject fails                                                                              |\n| `keda.scaledobject.removed.v1`             | When a ScaledObject is deleted                                                                                                |\n| `keda.scaledobject.paused.v1`              | When a ScaledObject is paused                                                                                                 |\n| `keda.scaledobject.unpaused.v1`            | When a ScaledObject is unpaused                                                                                               |\n| `keda.scaledjob.ready.v1`                  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`      |\n| `keda.scaledjob.failed.v1`                 | If the check validation for a ScaledJob fails                                                                                 |\n| `keda.scaledjob.removed.v1`                | When a ScaledJob is deleted                                                                                                   |\n| `keda.scaledjob.paused.v1`                 | When a ScaledJob is paused                                                                                                    |\n| `keda.scaledjob.unpaused.v1`               | When a ScaledJob is unpaused                                                                                                  |\n| `keda.scaledjob.rolloutcleanup.started.v1` | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob                                                |\n| `keda.scaledjob.rolloutcleanup.completed.v1` | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob                                            |\n| `keda.scaledjob.rolloutcleanup.failed.v1`  | When KEDA fails to delete a Job owned by the previous version of a ScaledJob                                                  |\n| `keda.authentication.triggerauthentication.created.v1` | On the first time a TriggerAuthentication is created                                                              |\n| `keda.authentication.triggerauthentication.updated.v1` | When a TriggerAuthentication is updated                                                                           |\n| `keda.authentication.triggerauthentication.removed.v1` | When a TriggerAuthentication is deleted                                                                           |\n| `keda.authentication.clustertriggerauthentication.created.v1` | On the first time a ClusterTriggerAuthentication is created                                                |\n| `keda.authentication.clustertriggerauthentication.updated.v1` | When a ClusterTriggerAuthentication is updated                                                             |\n| `keda.authentication.clustertriggerauthentication.removed.v1` | When a ClusterTriggerAuthentication is deleted                                                             |"
  },
  {
    "path": "content/docs/2.20/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA  | Kubernetes    |\n| ----- | ------------- |\n| v2.20 | TBD           |\n| v2.19 | v1.32 - v1.34 |\n| v2.18 | v1.31 - v1.33 |\n| v2.17 | v1.30 - v1.32 |\n| v2.16 | v1.29 - v1.31 |\n| v2.15 | v1.28 - v1.30 |\n| v2.14 | v1.27 - v1.29 |\n| v2.13 | v1.27 - v1.29 |\n| v2.12 | v1.26 - v1.28 |\n| v2.11 | v1.25 - v1.27 |\n| v2.10 | v1.24 - v1.26 |\n| v2.9  | v1.23 - v1.25 |\n| v2.8  | v1.17 - v1.25 |\n| v2.7  | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment         | CPU                     | Memory                        |\n| ------------------ | ----------------------- | ----------------------------- |\n| Admission Webhooks | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Metrics Server     | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator           | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout, although some scalers allow you to override this global setting via the `timeout` parameter in the trigger metadata.\n\n## HTTP Connection: Disable Keep Alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## HTTP TLS min version\n\nOur industry has seen an evolution of TLS versions and some are more secure than another. For example, TLS1.0 and TLS1.1 have known vulnerabilities.\n\nBy default, KEDA uses TLS1.2 as a minimum TLS version given it is the lowest version without vulnerabilities. However, if you need to support another version you can configure it by using the environment variable `KEDA_HTTP_MIN_TLS_VERSION`.\n\nFor example:\n\n```yaml\n- env:\n    KEDA_HTTP_MIN_TLS_VERSION: TLS13\n```\n\nThe following values are allowed: `TLS13`, `TLS12`, `TLS11` and `TLS10`.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## gRPC Metrics Service Parameters\n\nThe gRPC Metrics Service is part of the KEDA Operator deployment and serves scaling events and metrics from the scalers over gRPC to the Metrics API Service, that in turn serves them to the Kubernetes API Server. The gRPC Metrics Service config used by the KEDA Metrics Adapter to connect to the KEDA Operator can be adjusted by passing the following command-line flags to the Adapter binary:\n\n| Adapter Flag                   | Default Value                             | Description                                                                                                                                                                                                                                                                                               |\n| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| metrics-service-address        | keda-operator.keda.svc.cluster.local:9666 | The address of the gRPC Metrics Service Server                                                                                                                                                                                                                                                            |\n| metrics-service-grpc-authority | \"\"                                        | Host Authority override for the Metrics Service if the Host Authority is not the same as the address used for the gRPC Metrics Service Server. This is required for mutual TLS when the identity of the adapter server as presented in its TLS certificate is not the same as the metrics-service-address |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment | Default Value | Affected reconciler    |\n| ------------------------------------- | ---------- | ------------- | ---------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator   | 5             | ScaledObjectReconciler |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator   | 1             | ScaledJobReconciler    |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA Operator also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for the Operator Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n\n## Restrict the Namespaces KEDA is Watching\n\nBy default, KEDA controller watches for events in all namespaces in Kubernetes cluster. However, this can be restricted by environment variable `WATCH_NAMESPACE`.\nIt accepts either a single namespace, list of namespaces separated by comma or an empty string that denotes all namespaces.\n\nWhen a certain namespace is configured, and then a `ScaledObject` or `ScaledJob` is created in a different namespaces, it will be ignored by the operator.\n\nExample:\n\n```yaml\n- env:\n    WATCH_NAMESPACE: keda,production\n```\n\n## Certificates used by KEDA Metrics Server\n\nTo learn more please refer to [security section](./security#use-your-own-tls-certificates)\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n\n## Restrict Custom Resources\n\nAs KEDA supports scaling any workload inside the cluster, there is a non restrictive RBAC rule applied to all the cluster\n\n```yaml\n- apiGroups:\n    - *\n  resources:\n    - */scale\n  verbs:\n    - get\n    - list\n    - patch\n    - update\n    - watch\n- apiGroups:\n    - *\n  resources:\n    - *\n  verbs:\n    - get\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces as well as any workload type accross all the cluster.\n\nTo limit this permissions, you can review and adapt the RBAC generated by KEDA based on your necessities to only grant those permissions that you intentionally want to grant.\n\n> Note: If you are using KEDA's helm chart, you can totally disable Custom Resources via `rbac.enabledCustomScaledRefKinds` or limit the current `*` setting only your needed resources via `rbac.scaledRefKinds`.\n\n> It is always recommended to review the final generated role for KEDA components to ensure no broad permissions are assigned if the Helm template was customized. To quickly verify typical cases like blocked access to secrets, any tool used to analyze K8s RBAC can be used (e.g. https://github.com/aquasecurity/kubectl-who-can).\n\n\n## Logs\n\nKEDA uses zap to emit logs. The following flags can be used to configure logging behavior in both the metrics-apiserver and operator:\n\n- zap-encoder: Zap log encoding (one of `json` or `console`). Default is `console`\n- zap-log-level: Zap Level to configure the verbosity of logging. Can be one of `debug`, `info`, `error`,\n  or any integer value > 0 which corresponds to custom debug levels of increasing verbosity\". Default is `info`.\n- zap-time-encoding: Zap time encoding (one of `epoch`, `millis`, `nano`, `iso8601`, `rfc3339` or `rfc3339nano`),\n  Defaults is `rfc3339`.\n"
  },
  {
    "path": "content/docs/2.20/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA (external metrics only):\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"externalmetrics\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    }\n  ]\n}\n```\n\nIn order to query a specific metric value, you also can do it using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.20/operate/schema.md",
    "content": "+++\ntitle = \"Schema\"\ndescription = \"Specification & generation of KEDA scalers' schema\"\nweight = 100\n+++\n\n## Scaler Schema\n\nKEDA provides a separate scaler's schema for third-party usage ([scalers-metadata-schema.yaml](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.yaml)/[scalers-metadata-schema.json](https://github.com/kedacore/keda/blob/main/schema/generated/scalers-metadata-schema.json)). The schema file will keep updating according to the scaler's refactor.\n\n*Notice: The schema file still lacks some of the scalers. It will be completed once all scalers are refactored to use the new declarative scaler config.\n\n## Specification\n\nHere is a the schema of the scalers:\n\n```\nkedaVersion: main \nschemaVersion: 1\nscalers:\n    - type: activemq\n      parameters:\n        - name: managementEndpoint\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: destinationName\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: brokerName\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: username\n          type: string\n          metadataVariableReadable: true\n          envVariableReadable: true\n          triggerAuthenticationVariableReadable: true\n        - name: password\n          type: string\n          metadataVariableReadable: true\n          envVariableReadable: true\n          triggerAuthenticationVariableReadable: true\n        - name: corsHeader\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: restAPITemplate\n          type: string\n          optional: true\n          metadataVariableReadable: true\n        - name: targetQueueSize\n          type: string\n          default: \"10\"\n          metadataVariableReadable: true\n        - name: activationTargetQueueSize\n          type: string\n          default: \"0\"\n          metadataVariableReadable: true\n    - type: apache-kafka\n      parameters:\n        - name: bootstrapServers\n        ...\n\n```\n\n**Metadata field's property detail:**\n| Property  | Description \n|--------------|------------\n| name         | the name of the field\n| type         | type is the variable type of the field\n| optional     | optional is a boolean that indicates if the field is optional\n| default      | default is the default value of the field \n| allowedValue | allowedValue is a list of allowed values for the field\n| deprecated   | deprecated is a string that indicates if the field is deprecated\n| deprecatedAnnounce | deprecatedAnnounce is a string that indicates the deprecation message\n| separator | separator is the symbol that separates the value of the field if the value is a list string\n| exclusiveSet | exclusiveSet is a list of fields that are exclusive with the field\n| rangeSeparator | rangeSeparator is the symbol that indicates the range of the field\n| metadataVariableReadable | metadataVariableReadable is a boolean that indicates if the field can be read from the environment\n| envVariableReadable | envVariableReadable is a boolean that indicates if the field can be read from the environment\n| triggerAuthenticationVariableReadable | triggerAuthenticationVariableReadable is a boolean that indicates if the field can be read from the trigger authentication\n\n## Generation\n\nThere are two ways to generate scaler schemas:\n\n1. Run the GO file in the schema folder directly\n```\ngo run schema/generate_scaler_schema.go\nparameters:\n  --keda-version string                Set the version of current KEDA in schema. (default \"1.0\")\n  --kubeconfig string                  Paths to a kubeconfig. Only required if out-of-cluster.\n  --output-file-path string            scaler-metadata-schemas.yaml output file path. (default \"./\")\n  --scalers-builder-file buildScaler   The file that exists buildScaler func. (default \"../pkg/scaling/scalers_builder.go\")\n  --scalers-files-dir string           The directory that exists all scalers' files. (default \"../pkg/scalers\")\n  --specify-scaler string              Specify scaler name.\n```\n\n2. Use makefile\n```\nmake  generate-scaler-schemas\nenv variables:\n    OUTPUT_FILE_PATH          scaler-metadata-schemas.yaml output file path. (default \"./\")\n    SCALERS_BUILDER_FILE   The file that exists buildScaler func. (default \"../pkg/scaling/scalers_builder.go\")\n    SCALERS_FILES_DIR           The directory that exists all scalers' files. (default \"../pkg/scalers\")\n```\n\n SCALERS_BUILDER_FILE ?= \"pkg/scaling/scalers_builder.go\" \n SCALERS_FILES_DIR ?= \"pkg/scalers\" \n OUTPUT_FILE_PATH ?= \"schema/\"\n"
  },
  {
    "path": "content/docs/2.20/operate/security.md",
    "content": "+++\ntitle = \"Security\"\ndescription = \"Guidance to configure security options\"\nweight = 100\n+++\n\n## Use your own TLS Certificates\n\nKEDA uses self-signed certificates for different things. These certificates are generated and rotated by the operator. Certificates are stored in a Kubernetes secret (`kedaorg-certs`) that it's mounted to all KEDA components in the (default) path `/certs`. Generated files are named `tls.crt` and `tls.key` for TLS certificate and `ca.crt` and `ca.key` for CA certificate. KEDA also patches Kubernetes resources to include the `caBundle`, making Kubernetes to trust in the CA.\n\nThe KEDA operator is responsible for generating certificates for all the services, certificates are by default generated for following DNS names:\n```\n<KEDA_OPERATOR_SERVICE>                          -> eg. keda-operator\n<KEDA_OPERATOR_SERVICE>.svc                      -> eg. keda-operator.svc\n<KEDA_OPERATOR_SERVICE>.svc.<CLUSTER_DOMAIN>     -> eg. keda-operator.svc.cluster.local\n```\nTo change the default cluster domain (`cluster.local`), parameter `--k8s-cluster-domain=\"my-domain\"` on KEDA operator can be used. Helm Charts set this automatically from `clusterDomain` value.\n\nWhile this is a good starting point, some end-users may want to use their own certificates which are generated from their own CA in order to improve security. This can be done by disabling the certificate generation/rotation in the operator and updating default values in other components (if required). \n\nCertificates generation in the KEDA operator can be disabled by removing the console argument `--enable-cert-rotation=true` or setting it to `false`. Once this setting is disabled, user given certs can be placed in the secret `kedaorg-certs` which is automatically mounted in all the components or they can be patched to use other secret (this can be done through helm values too).\n\nAdditionally, KEDA includes a new `--enable-webhook-patching` flag, which controls whether the operator patches webhook resources. By default, this is set to `true`, ensuring Kubernetes trusts the operator's CA. However, if webhooks are disabled or not needed in your deployment, you can set this flag to `false` to avoid errors related to missing webhook resources.\n\nExample use case:\n- When using operator-managed certificates but disabling webhooks, set `--enable-webhook-patching=false` to prevent the operator from attempting to patch non-existent webhook resources.\n\nAll components inspect the folder `/certs` for any certificates inside it. Argument `--cert-dir` can be used to specify another folder to be used as a source for certificates, this argument can be patched in the manifests or using Helm values. Because these certificates are also used for internal communication between KEDA components, the CA is also required to be registered as a trusted CA inside KEDA components.\n\n## Register your own CA in KEDA Operator Trusted Store\n\nThere are use cases where we need to use self-signed CAs (cases like AWS where their CA isn't registered as trusted etc.). Some scalers allow skipping the cert validation by setting the `unsafeSsl` parameter, but this isn't ideal because it allows any certificate, which is not secure.\n\nTo overcome this problem, KEDA supports registering custom CAs to be used by SDKs where it is possible. To register custom CAs, place the certificates in a directory, then pass the directory to the KEDA operator using the `--ca-dir=` flag. By default, the KEDA operator looks in the `/custom/ca` directory.  Multiple directories can be specified by providing the `--ca-dir=` flag multiple times. KEDA will try to register as trusted CAs all certificates inside these directories. If using kustomize or helm, CA certificate directories can be specified via `certificates.operator.caDirs` and certificate volumes can be mounted using `volumes.keda.extraVolumes` and `volumes.keda.extraVolumeMounts`.\n"
  },
  {
    "path": "content/docs/2.20/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\nweight = 2\n+++\n\nReference information for the KEDA autoscaler.\n\n- [ScaledObject specification](./scaledobject-spec)\n- [ScaledJob specification](./scaledjob-spec)\n- [Kubernetes Events](./events)\n- [Firewall requirements](../operate/cluster#firewall)\n- [FAQ](./faq.md)\n- [Glossary](./glossary.md)\n"
  },
  {
    "path": "content/docs/2.20/reference/events.md",
    "content": "+++\ntitle = \"Events reference\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 2500\n+++\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/):\n\n| Event                                 | Type      | Description                                                                                                                 |\n|---------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectUpdateFailed`            | `Warning` | When KEDA fails to update status for a ScaledObject                                                                         |\n| `ScaledJobUpdateFailed`               | `Warning` | When KEDA fails to update status for a ScaledJob                                                                            |\n| `ScaledObjectPaused`                  | `Normal`  | When a ScaledObject is paused                                                                                               |\n| `ScaledObjectUnpaused`                | `Normal`  | When a ScaledObject is unpaused                                                                                             |\n| `ScaledObjectFallbackActivated`       | `Normal`  | When a ScaledObject fallback becomes active                                                                                 |\n| `ScaledObjectFallbackDeactivated`     | `Normal`  | When a ScaledObject fallback becomes inactive                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `ScaledJobPaused`                     | `Normal`  | When a ScaledJob is paused                                                                                                  |\n| `ScaledJobUnpaused`                   | `Normal`  | When a ScaledJob is unpaused                                                                                                |\n| `ScaledJobPauseFailed`                | `Warning` | When KEDA fails to pause a ScaledJob                                                                                        |\n| `ScaledJobRolloutCleanupStarted`      | `Normal`  | When KEDA starts cleaning up Jobs owned by the previous version of a ScaledJob                                              |\n| `ScaledJobRolloutCleanupCompleted`    | `Normal`  | When KEDA completes cleanup of Jobs owned by the previous version of a ScaledJob                                            |\n| `ScaledJobRolloutCleanupFailed`       | `Warning` | When KEDA fails to delete a Job owned by the previous version of a ScaledJob                                                |\n| `ScaledJobActive`                     | `Normal`  | When a ScaledJob becomes active (triggers are active and scaling is performed)                                              |\n| `ScaledJobInactive`                   | `Normal`  | When a ScaledJob becomes inactive (triggers are not active and scaling is not performed)                                    |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAMetricSourceFailed`              | `Warning` | When a scaler fails as a metric source for custom formula                                                                   |\n| `KEDAScalerInfo`                      | `Normal`  | When a Scaler contains deprecated field                                                                                     |\n| `KEDAScalerInfo`                      | `Warning` | When a Scaler contains unexpected parameter (disabled by default, enable with `KEDA_CHECK_UNEXPECTED_SCALERS_PARAMS`)       |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1, triggered by {scalers1;scalers2;...} |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `KEDAJobCreateFailed`                 | `Warning` | When KEDA fails to create a Job for a ScaledJob                                                                             |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationUpdated`        | `Normal`  | When a TriggerAuthentication is updated                                                                                     |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationUpdated` | `Normal`  | When a ClusterTriggerAuthentication is updated                                                                              |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.20/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\nweight = 2000\n+++\n\n{{< faq20 versionData=\"faq2_19\" >}}\n"
  },
  {
    "path": "content/docs/2.20/reference/glossary.md",
    "content": "+++\ntitle = \"Glossary\"\nweight = 1000\n+++\n\nThis document defines the various terms needed to understand the documentation and set up and use KEDA.\n\n## Admission Webhook\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/), an HTTP callback that handle admission requests. KEDA uses an admission webhook to validate and mutate ScaledObject resources.\n\n## Agent\n\nA primary role held by the KEDA operator. The Agent activates and deactivates Kubernetes Deployments to scale to and from zero.\n\n## Cluster\n\n[In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-cluster), a set of one or more nodes that run containerized applications.\n\n## CRD \n\nCustom Resource Definition. [In Kubernetes](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-CustomResourceDefinition), a custom resource that extends the Kubernetes API with custom resources like ScaledObjects that have custom fields and behavior.\n\n## Event\n\nA notable occurrence captured by an event source that KEDA may use as a trigger to scale a container or deployment.\n\n## Event Source\n\nAn external system like Kafka, RabbitMQ, that generates events that KEDA can monitor using a scaler.\n\n## Grafana\n\nAn open-source monitoring platform that can visualize metrics collected by KEDA.\n\n## gRPC Remote Procedure Calls (gRPC)\n\ngRPC Remote Procedure Calls (gRPC). An open-source remote procedure call framework used by KEDA components to communicate.\n\n## HPA \n\nHorizontal Pod Autoscaler. Kubernetes autoscaler. By default, scales based on CPU/memory usage. KEDA uses HPA to scale Kubernetes clusters and deployments.\n\n## KEDA \n\nKubernetes Event-Driven Autoscaling. A single-purpose, lightweight autoscaler that can scale a Kubernetes workload based on event metrics.\n\n## Metric\n\nMeasurement of an event source such as queue length or response lag that KEDA uses to determine scaling.\n\n## OpenTelemetry \n\nAn observability framework used by KEDA to instrument applications and collect metrics.\n\n## Operator\n\nThe core KEDA component that monitors metrics and scales workloads accordingly.\n\n## Prometheus\n\nAn open-source monitoring system that can scrape and store metrics from KEDA.\n\n## Scaled Object\n\nA custom resource that defines how KEDA should scale a workload based on events.\n\n## Scaled Job\n\nA custom resource KEDA uses to scale an application.\n\n## Scaler\n\nA component that integrates KEDA with a specific event source to collect metrics.\n\n## Stateful Set\n\nA Kubernetes workload with persistent data. KEDA can scale stateful sets.\n\n## TLS\n\nTransport Layer Security. KEDA uses TLS to encrypt communications between KEDA components.\n\n## Webhook\n\nAn HTTP callback used to notify KEDA of events from external sources.\n\n[In Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/webhook/), an HTTP callback used as an event notification mechanism.\n"
  },
  {
    "path": "content/docs/2.20/reference/scaledjob-spec.md",
    "content": "+++\ntitle = \"ScaledJob specification\"\nweight = 4000\n+++\n\n## Overview\n\nThis specification describes the `ScaledJob` custom resource definition that defines the triggers and scaling behaviors use by KEDA to scale jobs. The `.spec.ScaleTargetRef` section holds the reference to the job, defined in [_scaledjob_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\n  labels:\n    my-label: {my-label-value}                # Optional. ScaledJob labels are applied to child Jobs\n  annotations:\n    autoscaling.keda.sh/paused: true          # Optional. Use to pause autoscaling of Jobs\n    my-annotation: {my-annotation-value}      # Optional. ScaledJob annotations are applied to child Jobs\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the job's [pod template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## jobTargetRef\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n\n## pollingInterval\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n\n## successfulJobsHistoryLimit, failedJobsHistoryLimit\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n\n## envSourceContainerName\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n|--------------|-------------------|----------------------|-------------------|---------------------|\n| 10           | 3                 | 1                    | 0                 | 3                   |\n| 10           | 3                 | 2                    | 0                 | 3                   |\n| 10           | 3                 | 1                    | 1                 | 2                   |\n| 10           | 100               | 1                    | 0                 | 10                  | \n| 4            | 3                 | 5                    | 0                 | 1                   |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n\n## rollout\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default, the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n## scalingStrategy\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, `accurate`, or `eager`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n**eager**\nWhen adopting the **default** strategy, you are likely to come into a subtle case where messages need to be consumed by spawning jobs but remain in the queue, even when there are available slots between `runningJobCount` and `maxReplicaCount`. The **eager** strategy comes to the rescue. It addresses this issue by utilizing all available slots up to the maxReplicaCount, ensuring that waiting messages are processed as quickly as possible.\n\nFor example, let's assume we configure a ScaledJob in a cluster as below:\n```yaml\n  ###\n  # A job that runs for a minimum of 3 hours.\n  ###\n  pollingInterval: 10 # Optional. Default: 30 seconds\n  maxReplicaCount: 10 # Optional. Default: 100\n  triggers:\n    - type: rabbitmq\n      metadata:\n        queueName: woker_queue\n        hostFromEnv: RABBITMQ_URL\n        mode: QueueLength\n        value: \"1\"\n```\nWe send 3 messages to the Rabbitmq and wait longer enough than the `pollingInterval`, then send another 3.\n\nWith the `default` scaling strategy, we are supposed to see the metrics changes in the following table:\n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 3          |\n\n\nIf we switch to `eager`, the result becomes: \n\n|             | initial | incoming 3 messages | after poll | incoming 3 messages | after poll |\n|-------------|---------|---------------------|------------|---------------------|------------|\n| queueLength | 0       | 3                   | 3          | 6                   | 6          |\n| runningJobs | 0       | 0                   | 3          | 3                   | 6          |\n\nWe can identify the difference in their final states.\n\n\nYou may also refer to [this original issue](https://github.com/kedacore/keda/issues/5114) for more information.\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n\n### multipleScalersCalculation\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n"
  },
  {
    "path": "content/docs/2.20/reference/scaledobject-spec.md",
    "content": "\n+++\ntitle = \"ScaledObject specification\"\nweight = 3000\n+++\n\n## Overview\n\nThis specification describes the `ScaledObject` Custom Resource definition that defines the triggers and scaling behaviors used by KEDA to scale `Deployment`, `StatefulSet` and `Custom Resource` target resources. The `.spec.ScaleTargetRef` section holds the reference to the target resource, defined in [_scaledobject_types.go_](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  annotations:\n    scaledobject.keda.sh/transfer-hpa-ownership: \"true\"     # Optional. Use to transfer an existing HPA ownership to this ScaledObject\n    validations.keda.sh/hpa-ownership: \"true\"               # Optional. Use to disable HPA ownership validation on this ScaledObject\n    autoscaling.keda.sh/paused: \"true\"                      # Optional. Use to pause autoscaling of objects explicitly\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}         # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}                # Optional. Default: Deployment\n    name:          {name-of-target-resource}                # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}                # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                                      # Optional. Default: 30 seconds\n  cooldownPeriod:   300                                     # Optional. Default: 300 seconds\n  initialCooldownPeriod:  0                                 # Optional. Default: 0 seconds\n  idleReplicaCount: 0                                       # Optional. Default: ignored, must be less than minReplicaCount\n  minReplicaCount:  1                                       # Optional. Default: 0\n  maxReplicaCount:  100                                     # Optional. Default: 100\n  fallback:                                                 # Optional. Section to specify fallback options\n    failureThreshold: 3                                     # Mandatory if fallback section is included\n    replicas: 6                                             # Mandatory if fallback section is included\n    behavior: {kind-of-behavior}                            # Optional. Default: \"static\"\n  advanced:                                                 # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false               # Optional. Default: false\n    horizontalPodAutoscalerConfig:                          # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                          # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                             # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n## scaleTargetRef\n\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` need be specified. To scale a different resource such as StatefulSet or Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n\n## pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA. For example, if this parameter is set to `60`, KEDA will poll for a metric value every 60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly for metrics, based on the [`--horizontal-pod-autoscaler-sync-period`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options) parameter to the `kube-controller-manager`, which by default is 15 seconds. For example, if the `kube-controller-manager` was started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll for a metric value every 30 seconds while the number of replicas is between 1 and N.\n\nIf you want respect the polling interval, the feature [`caching metrics`](../concepts/scaling-deployments/#caching-metrics) enables caching of metric values during polling interval.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval` while the number of replicas is 0, and scale the resource up an down accordingly.\n\n## cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0, in seconds. By default, it's 300 (5 minutes).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n\n## initialCooldownPeriod\n```yaml\n   initialCooldownPeriod:  120 # Optional. Default: 0 seconds\n```\nThe delay before the `cooldownPeriod` starts after the initial creation of the `ScaledObject`, in seconds. By default, it's 0, meaning the `cooldownPeriod` begins immediately upon creation. If set to a value such as 120 seconds, the `cooldownPeriod` will only start after the `ScaledObject` has been active for that duration.\n\nThis parameter is particularly useful for managing the scale-down behavior during the initial phase of a `ScaledObject`. For instance, if `initialCooldownPeriod` is set to 120 seconds, KEDA will not scale the resource back to 0 until 120 seconds have passed since the `ScaledObject` creation, regardless of the activity triggers. This allows for a grace period in situations where immediate scaling down after creation is not desirable.\n\n**Example:** Wait 120 seconds after the `ScaledObject` is created before starting the `cooldownPeriod`. For instance, if the `initialCooldownPeriod` is set to 120 seconds, KEDA will not initiate the cooldown process until 120 seconds have passed since the `ScaledObject` was first created, regardless of the triggers' activity. This ensures a buffer period where the resource won’t be scaled down immediately after creation. (Note: This setting is independent of the `pollingInterval`.)\n\n\n## idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n\n## minReplicaCount\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n## maxReplicaCount\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n\n## fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n    behavior: \"static\"                               # Optional. Default: \"static\"\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nFallback is supported for all triggers of both `Value` and `AverageValue` metric types, except CPU & memory triggers. It's also only supported by `ScaledObjects`, not `ScaledJobs`.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behavior), the scaler will, instead, return a normalised metric using the formula for `AverageValue` metrics:\n```\ntarget metric value * fallback replicas\n```\nFor `Value` metrics it's using the formula:\n```\ntarget metric value * fallback replicas / current ready replicas\n```\n\nThese formulas offset the HPA's calculations and will cause it to scale the deployment to the specified number of fallback replicas.\n\n## fallback.behavior\n\nThe `behavior` option can be used to configure the final replica count calculation on the target deployment when fallback is used.\n\n#### `static` behavior\nWhen `behavior` is not specified or when `behavior` is given with value `static`, the number of replicas `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 6 with a `behavior` 'static'.\n\n#### `currentReplicas` behavior\nWhen using `behavior` with value `currentReplicas`, the current number of replicas is determined. This value will be used as fallback replicas.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when the current replicas are 6, with a `behavior` 'currentReplicas'.\n\n#### `currentReplicasIfHigher` behavior\nWhen using `behavior` with value `currentReplicasIfHigher`, the current number of replicas is determined. If the current number of replicas is higher than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is lower, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 6 replicas when I have `fallback.replicas` set to 3, but the current replicas are 6, with a `behavior` 'currentReplicasIfHigher'.\n\n#### `currentReplicasIfLower` behavior\nWhen using `behavior` with value `currentReplicasIfLower`, the current number of replicas is determined. If the current number of replicas is lower than `fallback.replicas`, this value will be used as fallback replicas. If the current number of replicas is higher, the value of `fallback.replicas` will be used.\n\n**Example:** When my Prometheus instance becomes unavailable 3 times in a row, KEDA changes the HPA metric to scale the deployment to 3 replicas when I have `fallback.replicas` set to 6, but the current replicas are 3, with a `behavior` 'currentReplicasILower'.\n\n## advanced\n\n### restoreToOriginalReplicaCount\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted.\nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n\n### horizontalPodAutoscalerConfig\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n          tolerance: 0.1                          # requires Kubernetes v1.33 or newer and feature gate \"HPAConfigurableTolerance\"\n```\n\n#### horizontalPodAutoscalerConfig.name\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n#### horizontalPodAutoscalerConfig.behavior\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n#### horizontalPodAutoscalerConfig.behavior tolerance\n\nAs of Kubernetes v1.34 the `tolerance` field can be specified under the HPA behavior policy `scaleUp` and `scaleDown` sections. The field applies a tolerance thresholds for scaling decisions, allowing you to specify different behavior for scale-up and scale-down operations. This field was in alpha release under Kubernetes v1.33, which can be enabled through the Kubernetes `HPAConfigurableTolerance` feature gate. As of Kubernetes v1.34, this field has graduated to beta release and is specifiable by default.\n\n### scalingModifiers\n\nIf defined, both `target` and `formula` are mandatory. Using this structure creates `composite-metric` for the HPA that will replace all requests for external metrics and handle them internally. With `scalingModifiers` each trigger used in the `formula` **must** have a name defined.\n\n```yaml\nadvanced:\n  scalingModifiers:                                       # Optional. Section to specify scaling modifiers\n    target: {target-value-to-scale-on}                        # Mandatory. New target if metrics are anyhow composed together\n    activationTarget: {activation-target-value-to-scale-on}   # Optional. New activation target if metrics are anyhow composed together\n    metricType:  {metric-type-for-the-modifier}               # Optional. Metric type to be used if metrics are anyhow composed together\n    formula: {formula-for-fetched-metrics}                    # Mandatory. Formula for calculation\n```\n\n#### scalingModifiers.target\n\n`target` defines new target value to scale on for the composed metric.\n\n#### scalingModifiers.activationTarget\n\n`activationTarget` defines a new [activation target value](../concepts/scaling-deployments.md#activating-and-scaling-thresholds) to scale on for the composed metric. (Default: `0`, Optional).\n\nThere is one important exception to the activation target for scaling modifiers and that is [external push scalers](../concepts/external-scalers). These scalers can implement `StreamIsActive` gRPC method which pushes activation status to KEDA directly, regardless of what the metric value and activation target is.\n\n#### scalingModifiers.metricType\n\n`metricType` defines metric type used for this new `composite-metric`. (Values: `AverageValue`, `Value`, Default: `AverageValue`, Optional)\n\n#### scalingModifiers.formula\n\n  `formula` composes metrics together and allows them to be modified/manipulated. It accepts mathematical/conditional statements using [this external project](https://github.com/antonmedv/expr). If the `fallback` scaling feature is in effect, the `formula` will NOT modify its metrics (therefore it modifies metrics only when all of their triggers are healthy). Complete language definition of `expr` package can be found [here](https://expr.medv.io/docs/Language-Definition). Formula must return a single value (not boolean).\n\nFor examples of this feature see section [Scaling Modifiers](../concepts/scaling-deployments.md).\n\n\n## triggers\n\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](../scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default, the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics\"](../concepts/scaling-deployments.md#caching-metrics). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](../concepts/authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n"
  },
  {
    "path": "content/docs/2.20/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.20/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/apache-kafka-go.md",
    "content": "+++\ntitle = \"Apache Kafka (Experimental)\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Experimental scaler based on 'segmentio/kafka-go' library. Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"apache_kafka_scaler\"\n+++\n\n> **Notice:**\n> - This is an experimental Kafka scaler based on [kafka-go](https://github.com/segmentio/kafka-go) library.\n> - This scaler is not fully compatible with the existing [Kafka scaler](./apache-kafka.md). There are some differences in the configuration and behavior. Please read the documentation carefully before using it. \n> - If you are using OAuth authentication, please use the existing Kafka scaler, as this scaler does not yet support OAuth2 authentication.\n> - This scaler has support for AWS MSK IAM based authentication.\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `apache-kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: apache-kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: false\n    scaleToZeroOnInvalidOffset: false\n    excludePersistentLag: false\n    limitToPartitionsWithLag: false\n    ensureEvenDistributionOfPartitions: false\n    partitionLimitation: '1,2,10-20,31'\n    tls: enable\n    sasl: plaintext\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Average target value to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, the feature is still a WIP and as such would highly recommend to specify `topic` to avoid unexpected behavior. Namely the scaler will not be able to determine the topics it had subscribed to in the past and will not be able to calculate the lag for those topics.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`.\n\n If TLS is required you should set tls to enable. If required for your Kafka configuration, you may also provide a ca, cert, key and keyPassword. cert and key must be specified together. Another alternative is to specify tls and sasl in ScaledObject instead of tls and sasl in TriggerAuthentication, respectively.\n\n In case of SASL based authentication provide the `username` and `password`.\n \n For AWS MSK IAM authentication provide `aws_msk_iam` as `sasl`. You don't need to set `username` and `password` in this case. However, you need to enable TLS by setting `tls` to `enable`.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `aws_msk_iam` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n- `password` - Password used for sasl authentication. (Required if `sasl` is not `none` or `aws_msk_iam`)\n\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n**AWS MSK IAM Specific Configuration:**\n\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\nFor authentication, you can also use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn`.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### New `ensureEvenDistributionOfPartitions` property support\n\nWhen scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to.\n\nConsider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution.\n\nBelow are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default.\n\n- For lag between `1 -> 10` we would be running `1` consumer\n- For lag between `11 -> 20` we would be running `2` consumer\n- For lag between `21 -> 50` we would be running `5` consumers\n- For lag higher than `51` we would be running `10` consumers\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>   - The number of partitions with non-zero lag if `limitToPartitionsWithLag` is set to `true`\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    limitToPartitionsWithLag: 'false'\n    ensureEvenDistributionOfPartitions: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n    sasl: plaintext\n    tls: enable\n    unsafeSsl: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `limitToPartitionsWithLag` - When set to `true`, the number of replicas will not exceed the number of partitions having non-zero lag. `topic` must be specified when this parameter is set to `true`. `allowIdleConsumers` cannot be `true` when this parameter is `true`. (Default: `false`, Optional)\n- `ensureEvenDistributionOfPartitions` - When set to `true`, the scaler will ensure that the number of replicas is even across the topic partitions. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer`, or `none`, Default: `none`, Optional). This parameter could also be specified in `sasl` in TriggerAuthentication. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence.\n- `saslTokenProvider` - Kafka SASL token provider when `sasl` is `oauthbearer`. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional). This parameter could also be specified in `saslTokenProvider` in TriggerAuthentication. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence.\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional). This parameter could also be specified in `tls` in TriggerAuthentication. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `awsRegion` - AWS region of your MSK cluster. (Optional, required for AWS MSK IAM authentication)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on.  If you are using SASL/GSSAPI, you will need to provide Kerberos user, password or keytab, realm and krb5.conf file. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. You can also add custom SASL extension for OAuthbearer (see [KIP-342](https://cwiki.apache.org/confluence/display/KAFKA/KIP-342%3A+Add+support+for+Custom+SASL+extensions+in+OAuthBearer+authentication)) using `oauthExtensions`.\n If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n Another alternative is to specify `tls` and `sasl` in ScaledObject instead of `tls` and `sasl` in TriggerAuthentication, respectively. If specified in both ScaledObject and TriggerAuthentication, the value in ScaledObject takes precedence. For AWS MSK IAM authentication, you only need to set `awsRegion` in ScaledObject and you also need to enable TLS by setting `tls` to enable.\n\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `gssapi`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `saslTokenProvider` - Kafka SASL token provider. (Values: `bearer`, `aws_msk_iam`, Default: `bearer`, Optional).\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `keytab` - Kerberos keytab.  Either `password` or `keytab` is required in case of `gssapi`.  (Optional)\n- `realm` - Kerberos realm.  (Optional unless sasl mode is `gssapi`)\n- `kerberosConfig` - Kerberos configuration file. (Optional unless sasl mode is `gssapi`)\n- `kerberosServiceName` - Kerberos service name. (Optional takes default value of `kafka` if not provided)\n- `kerberosDisableFAST` - To disable FAST negotiation, set this to `true` (Values: `true`, `false`, Default: `false`, Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbearer token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbearer token requests. (Optional)\n- `oauthExtensions` - A comma separated lists of key value pairs in the format key=value OAuth extensions used in the oauthbearer token. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**AWS MSK IAM Specific Configuration:**\n\nFor authentication, you must use `TriggerAuthentication` CRD to configure the authenticate by providing `awsAccessKeyID` and `awsSecretAccessKey` or `awsRoleArn` or a pod identity configuration.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### New `ensureEvenDistributionOfPartitions` property support\n\nWhen scaling a Kafka consumers, you would want to ensure that all partitions are consumed equally. Otherwise some partition would start building up higher lag than others. Prior to introduction of this parameter the Kafka scaler did not factor in the number of partitions on the Kafka topic in its scaling decisions. This is a problem because we could end up in a situation where your consumers would have uneven distribution of partitions. When you have `ensureEvenDistributionOfPartitions` configuration enabled the scaler would always ensure that the number of partitions are always balanced between the number of consumers that we would be scaling to.\n\nConsider for example a topic with `10` partitions. In this case the ideal consumer count should always be `1,2,5,10`. Running any other number of consumers than this set would cause an uneven distribution.\n\nBelow are some examples of what the scaling decision would look like. Consider `10` partitions and a lag threshold of `10` as the configuration default.\n\n- For lag between `1 -> 10` we would be running `1` consumer\n- For lag between `11 -> 20` we would be running `2` consumer\n- For lag between `21 -> 50` we would be running `5` consumers\n- For lag higher than `51` we would be running `10` consumers\n\n### Example\n\n#### Your kafka cluster has no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\n#### Your kafka cluster turns on SASL/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: plaintext\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL OAuthbearer/TLS auth:\n\n##### Method 1: `tls` and `sasl` are in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n##### Method 2: `tls` and `sasl` are in ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  oauthExtensions: \"extension_logicalCluster=1,extension_identityPoolId=2\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: oauthExtensions\n    name: keda-kafka-secrets\n    key: oauthExtensions\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      tls: enable\n      sasl: oauthbearer\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your kafka cluster turns on SASL/GSSAPI auth without TLS:\n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/kerberos\n            name: temp-kerberos-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-kerberos-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/kerberos\n  name: temp-kerberos-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-kerberos-vol\n  emptyDir:\n    medium: Memory\n```\n\n##### `sasl/gssapi` in TriggerAuthentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"gssapi\"\n  tls: \"disable\"\n  username: \"admin\"\n  realm: <your kerberos realm>\n  keytab: <your kerberos keytab>\n  kerberosConfig: <your kerberos configuration>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: realm\n    name: keda-kafka-secrets\n    key: realm\n  - parameter: keytab\n    name: keda-kafka-secrets\n    key: keytab\n  - parameter: kerberosConfig\n    name: keda-kafka-secrets\n    key: kerberosConfig\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\n#### Your AWS MSK has IAM auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  saslTokenProvider: \"aws_msk_iam\"\n  tls: \"enable\"\n  awsAccessKeyID: <your awsAccessKeyID>\n  awsSecretAccessKey: <your awsSecretAccessKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: saslTokenProvider\n    name: keda-kafka-secrets\n    key: saslTokenProvider\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: awsAccessKeyID\n    name: keda-kafka-secrets\n    key: awsAccessKeyID\n  - parameter: awsSecretAccessKey\n    name: keda-kafka-secrets\n    key: awsSecretAccessKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: apache-kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      awsRegion: us-east-1         # AWS region of your MSK cluster\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/arangodb.md",
    "content": "+++\ntitle = \"ArangoDB\"\navailability = \"v2.10+\"\nmaintainer = \"Community\"\ncategory = \"Datastore\"\ndescription = \"Scale applications based on ArangoDB query result.\"\ngo_file = \"arangodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `arangodb` trigger that scales based on a ArangoDB query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: arangodb\n  metadata:\n    # Required fields:\n    endpoints: \"https://<endpoint1>:8529,https://<endpoint2>:8529\" # Note: add one or more comma separated URL endpoints of all the coordinators\n    query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length} # Note: the query should return only a single numeric value in the JSON format {\"value\":<value>}\n    queryValue: '3'\n    dbName: gradesheet\n    collection: class\n    # Optional fields:\n    activationQueryValue: '3'\n    connectionLimit: 13 \n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs\n```\n\n**Parameter list:**\n\n- `endpoints` - ArangoDB server endpoint URL or comma separated URL endpoints of all the coordinators. It can also be provided as an authentication parameter.\n- `query` - ArangoDB query to scale for. Please note that the query should return only a single numeric value, i.e. an integer or a float, in the JSON format `{\"value\":<value>}`.\n- `dbName` - Name of the database. It can also be provided as an authentication parameter.\n- `collection` - Name of the collection.\n- `threshold` - A threshold that will define when scaling should occur.\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `serverID` - The unique ArangoDB server ID. Only required if bearer JWT is being used. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `connectionLimit` - Specify the max size of the active connection pool. (Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nArangoDB provides SSL/TLS configured out of the box. For authentication, it can be configured along with a Basic Auth or Bearer Auth.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\nAdditionally, the parameters `endpoints` and `dbName` can also be provided as authentication parameters.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: arangodb-deployment\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        activationQueryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n```\n\nHere is an example of a arangodb scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-arangodb-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        serverID: \"uDmcE-0Zd\"\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n\nHere is an example of a arangodb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-arangodb-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-arangodb-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-arangodb-secret\n      key: username\n    - parameter: password\n      name: keda-arangodb-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: arangodb-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: arangodb\n      metadata:\n        endpoints: https://<endpoint>:8529\n        queryValue: '3'\n        dbName: gradesheet\n        collection: class\n        query: FOR students IN class COLLECT WITH COUNT INTO length RETURN {\"value\":length}\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-arangodb-creds\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n**TLS authentication:**\n\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - Password for the client certificate private key. (Optional, Required when `key` is encrypted)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```\n\n### Example with TLS (HTTPS with self-signed certificates)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8443\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        unsafeSsl: \"true\"  # Skip certificate validation for self-signed certificates\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```\n\n### Example with mutual TLS (client certificates)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis-tls\n  namespace: kedartemis\ntype: Opaque\ndata:\n  artemis-ca: \"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=\"  # Base64 encoded CA certificate\n  artemis-cert: \"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCi4uLgo=\"  # Base64 encoded client certificate\n  artemis-key: \"LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCi4uLgo=\"  # Base64 encoded client private key\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis-tls\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: ca\n      name: kedartemis-tls\n      key: artemis-ca\n    - parameter: cert\n      name: kedartemis-tls\n      key: artemis-cert\n    - parameter: key\n      name: kedartemis-tls\n      key: artemis-key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8443\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n      authenticationRef:\n        name: trigger-auth-kedartemis-tls\n```"
  },
  {
    "path": "content/docs/2.20/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Optional: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    # Optional: metricName\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Optional: ignoreNullValues\n    ignoreNullValues: \"false\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: Specify metric source AWS Account ID when using CloudWatch cross-account observability\n    awsAccountId: \"\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsAccountId` - Specify metric source AWS Account ID when using CloudWatch cross-account observability\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `namespace` - AWS Cloudwatch namespace where the metric is located (Optional, Required when `expression` is not specified)\n- `metricName` - AWS Cloudwatch metric name (Optional, Required when `expression` is not specified)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). Supports all CloudWatch statistics including percentiles (e.g., `p95`, `p50`) and trimmed means (e.g., `tm99`, `tm95`). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `ignoreNullValues`- Describes the behaviour when the metric query returns no metric values in the response.  If set to `true`, the scaler will scale the workload based on the `minMetricValue` provided. If set to `false`, the scaler will return an error and not adjust the scale of the workload. When set to `false` this will take precedence over `minMetricValue`. (Default: `true`, Optional)\n\n> Both `minMetricValue` and `ignoreNullValues` are used to handle the case when the metric query returns no metric values in the response from AWS CloudWatch. `minMetricValue` will scale the workload based on the value provided, while `ignoreNullValues`, if false, will return an error and not adjust the scale of the workload.\n\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional: indexName\n    indexName: \"\"\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}, \":filterValue\" : {\"S\" : \"hello world\"}}'\n    # Optional: filterExpression\n    filterExpression: 'filterField = :filterValue'\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `indexName` - The index used by the DynamoDB Query. (Optional)\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `filterExpression` - the condition that specifies the filterExpression to be used by the Query action.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in v3. Optional # Optional. Default: pod\n    identityOwner: pod | operator\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The short name of the queue can be used if there's no ambiguity. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required. If both are provided, `queueURL` is used.)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional. Only one of `queueURL` and `queueURLFromEnv` is required.)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`. You can also include the number of delayed messages when calculating \"actual messages\" by setting `scaleOnDelayed` to `true`. With `scaleOnInFlight` and `scaleOnDelayed` set to `true` the formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible` + `ApproximateNumberOfMessagesDelayed`.\n\n- `scaleOnInFlight` - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)\n- `scaleOnDelayed` - Indication of whether or not to include delayed messages when calculating the number of SQS messages. (default: false, Optional)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (DEPRECATED: This parameter is deprecated as of KEDA v2.13 and will be removed in version `3`, Values: `pod`, `operator`, Default: `pod`, Optional, This field only applies for `aws-eks` authentication)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource. (This field is deprecated and only applies for `aws-eks` authentication, for `aws` is set in the auth)\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    ignoreNullValues: true # Default is `false`. Set to `true` to ignore any errors with data extraction from a successful query. Set to `false` the scaler will return error when null values are discovered \n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `ignoreNullValues` - Ignore any errors with data extraction from a successful query (Values: `true`,`false`, Default: `false`, Optional).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n\n> When using [pod identity](../authentication-providers/azure-ad-workload-identity.md), Microsoft Entra ID endpoint is recovered via `AZURE_AUTHORITY_HOST` env var provided by https://azure.github.io/azure-workload-identity/docs/installation/mutating-admission-webhook.html\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n      # Optional (Default: false)\n      unsafeSsl: \"false\"\n      # Optional. Custom timeout for the HTTP client used in this scaler\n      timeout: \"1000\"\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `unsafeSsl` - Determines whether or not KEDA will verify the server certificate's chain and host name. (Default: `false`, Optional, This value can be a bool)\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\nit's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n### Links\n\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n      # Optional: Demands of jobs must exactly match the capabilities the trigger defines\n      requireAllDemands: false\n      # Optional: Require jobs to include specified demands, ignoring any extra ones\n      requireAllDemandsAndIgnoreOthers: false\n      # Optional: How many jobs to fetch for the pool in the API (default: 250)\n      jobsToFetch: \"{jobsToFetch}\"\n      # Optional: Whether to only fetch unfinished jobs from the API (default: false)\n      fetchUnfinishedJobsOnly: false\n      # Optional: Property to enable case-insensitive comparison of pipeline job demands (default: false)\n      caseInsensitiveDemandsProcessing: false\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\". Mutually exclusive with `jobsToFetch`.\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n- `jobsToFetch` - The number of the jobs that KEDA will fetch for the pool from Azure Pipeline API. Mutually exclusive with `parent` and `fetchUnfinishedJobsOnly`. (Default: `250`, Optional)\n- `fetchUnfinishedJobsOnly` - Whether to fetch only unfinished jobs from the Azure Pipeline API. Normally both finished, running and pending jobs are returned by the API. When this parameter is set to `true`, the API call is modified so that only running and pending jobs are returned from the API, which reduces the amount of returned jobs considerably. Mutually exclusive with `jobsToFetch`. (Default: `false`, Optional)\n- `caseInsensitiveDemandsProcessing` - Property to enable case-insensitive comparison of pipeline job demands. When this parameter is set to `true`, the demands check is case-insensitive. (Default: `false`, Optional)\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token or Managed identity via `TriggerAuthentication` configuration. If `personalAccessTokenFromEnv` or `personalAccessTokenFrom` is empty `TriggerAuthentication` must be configured using podIdentity.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not use demands in your agent scaler then it scales based on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored).\n  - If `requireAllDemands` is set to `true`, the job's demands must match exactly with the triggers demands. This means a job with demands `maven` will not match an agent with capabilities `maven,java`.\n  - If `requireAllDemandsAndIgnoreOthers` is set to `true`, the job's demands must include all specified demands exactly, but any additional demands will be ignored. For instance, a job with demands `maven` will match an agent with capabilities `maven,java`, as long as `maven` is in the demand list.\n  - **Note:** `requireAllDemands` takes precedence over `requireAllDemandsAndIgnoreOthers`. If both are set to `true`, only exact matches are accepted.\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands:\n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\nHowever, as this an undocumented API, it possesses some unique quirks when calling it with different query parameters. For example, if the `$top` query parameter is given, the format of the returned JSON is changed in such a way that it is no longer possible for the scaler to find the matched agents; making it impossible to use with the `parent` property from the trigger metadata. Therefore making `jobsToFetch` mutually exclusive with `parent` in the trigger metadata.\n\nAdditionally, the `$top` query parameter takes precedence over some other parameters like `completedRequestCount`. If the `$top` query parameter is given, finished jobs are included in the response even if `completedRequestCount=0` is given, although `completedRequestCount=0` would indicate that only pending and running jobs should be returned. Thus, `jobsToFetch` is also mutually exclusive with `fetchUnfinishedJobsOnly` in the trigger metadata.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n### Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n\n```\n\n### Example for using pod identity authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n\n### Troubleshooting\n\n#### KEDA is unable to get queue information due to \"invalid queue runtime properties: no CountDetails element\"\n\nWhen KEDA logs show errors similar to `invalid queue runtime properties: no CountDetails element` it usually is caused because of throttling by Azure Service Bus.\n\nConsider applying one of the following mitigations:\n- Scaling the Azure Service Bus namespace to a higher SKU, or use premium\n- Increase the polling interval of the ScaledObject/ScaledJob\n- Use [caching of metrics](../concepts/scaling-deployments/#caching-metrics)\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    queueLengthStrategy: all|visibleonly\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `queueLengthStrategy` - `all` considers both visible and invisible messages, while `visibleonly` uses Peek to count only visible messages. In `visibleonly`, if the count of messages is 32 or higher, it falls back to the default `all` strategy, counting both visible and invisible messages. (Default: `all`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      # Optional\n      queueLengthStrategy: \"all\" # or visibleonly. Default: all\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/beanstalkd.md",
    "content": "+++\ntitle = \"Beanstalkd\"\navailability = \"v2.16+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on beanstalkd queues\"\ngo_file = \"beanstalkd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `beanstalkd` trigger that scales based on the number of jobs in a Beanstalkd queue.\n\n```yaml\ntriggers:\n  - type: beanstalkd\n    metadata:\n      server: beanstalkd.internal-namespace:11300\n      includeDelayed: \"false\"\n      tube: \"default\"\n      activationValue: \"10\"\n      value: \"15\"\n      timeout: \"30\"\n```\n\n**Parameter list:**\n\n- `server` - Address of beanstalkd server `<host>:<port>`. If no port is specified then the scaler will default to `11300`.\n- `includeDelayed` - Whether to include delayed jobs in the count used for scaling. Defaults to false so only `ready` and `reserved` jobs are counted.\n- `tube` - Name of the tube to scale on.\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `value` - Number of jobs in the queue to trigger on. Defaults to `ready`+`reserved` jobs if `includeDelayed` isn't set.\n- `timeout` - Timeout in seconds for establishing a connection to the beanstalkd server. (Default: `30`, Optional)\n\n### Authentication Parameters\n\nNo authentication should be needed to connect to the beanstalkd server.\n\n### Example\n\n#### Default tube with activation value\n\nHere the scaler will not be active until there are at least 10 jobs in the tube. Delayed jobs are not included as `includeDelayed` will be set to a default of `false`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'default'\n        activationValue: \"10\"\n        value: \"20\"\n```\n\n#### User-created tube with minimum replicas\n\nA minimum number of replicas is specified here so the scaler will always be active. This means scaling will occur as soon as the job count goes above 5. Delayed jobs are included here.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: beanstalkd-scaledobject\nspec:\n  scaleTargetRef:\n    name: beanstalkd-consumer\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n    - type: beanstalkd\n      metadata:\n        server: beanstalkd.internal-namespace:11300\n        tube: 'scaling-tube'\n        value: \"5\"\n        includeDelayed: \"true\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to log in to the Cassandra instance.\n- `tls` - To enable SSL auth for Cassandra session, set this to enable. If not set, TLS for Cassandra is not used. (Values: enable, disable, Default: disable, Optional).\n- `cert` - Certificate path for client authentication. Mandatory if tls enabled. (Optional)\n- `key` - Key path for client authentication. Mandatory if tls enabled. (Optional)\n\n### Example with no TLS auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n\n### Example with TLS auth\n\nSince we are passing Cert and Key content as inputs to the scaler, we have to supply writable location for required GSSAPI configurations for the `keda-operator` container. \n\n##### `sasl/gssapi` in manager.yaml\n\nIf you use YAML declarations to deploy KEDA, add below volume mount and volume to supply writable location for required GSSAPI configurations for the `keda-operator` container.\n\n```\n          volumeMounts:\n          - mountPath: /tmp/cassandra\n            name: temp-cassandra-vol\n            readOnly: false\n\n      volumes:\n      - name: temp-cassandra-vol\n        emptyDir:\n          medium: Memory\n```\n\n##### `sasl/gssapi` in keda-charts\n\nIf you use Helm Charts to deploy KEDA, add below volume mount and volume to supply writable location for required gssapi configurations.\n\n```\nvolumes.keda.extraVolumeMounts\n- mountPath: /tmp/cassandra\n  name: temp-cassandra-vol\n  readOnly: false\n\nvolumes.keda.extraVolumes\n- name: temp-cassandra-vol\n  emptyDir:\n    medium: Memory\n```\n\nOnce we have the writable mount path set up for the certificates and keys.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n  tls: enable\n  cert: <cert content | base64encoded>\n  key: <key content | base64encoded>\n  ## Optional parameter ca ##\n  ca: <ca cert content | base64encoded>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n  - parameter: tls\n    name: cassandra-secrets\n    key: tls\n  - parameter: cert\n    name: cassandra-secrets\n    key: cert\n  - parameter: key\n    name: cassandra-secrets\n    key: key\n  ## Optional parameter ca ##\n  - parameter: ca\n    name: cassandra-secrets\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + CPU, or Prometheus + CPU) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Scheduling\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be the same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale your deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do it the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.20/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\nThere are two ways to poll Datadog for a query value using the Datadog scaler: using the REST API endpoints, or using the [Datadog Cluster Agent](https://docs.datadoghq.com/containers/cluster_agent/) as proxy. Using the Datadog Cluster Agent as proxy reduces the chance of reaching rate limits. As both types are different in terms of usage and authentication, this documentation handles them separately.\n\n## Using the Datadog Cluster Agent (Experimental)\n\nWith this method, the Datadog scaler will be connecting to the Datadog Cluster Agent to retrieve the query values that will be used to drive the KEDA scaling events. This reduces the risk of reaching rate limits for the Datadog API, as the Cluster Agent retrieves metric values in batches.\n\n### Deploy the Datadog Cluster Agent with enabled external metrics\n\nFirst, deploy the Datadog Cluster Agent enabling the external metrics provider, but without registering it as an `APIService` (to avoid clashing with KEDA).\n\nIf you are using Helm to deploy the Cluster Agent, set:\n\n* `clusterAgent.metricsProvider.enabled` to `true`\n* `clusterAgent.metricsProvider.registerAPIService` to `false`\n* `clusterAgent.metricsProvider.useDatadogMetrics` to `true`\n* `clusterAgent.env` to `[{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]`\n\nIf you are using the Datadog Operator, add the following options to your `DatadogAgent` object:\n\n```\napiVersion: datadoghq.com/v2alpha1\nkind: DatadogAgent\nmetadata:\n  name: datadog\nspec:\n  features:\n    externalMetricsServer:\n      enabled: true\n      useDatadogMetrics: true\n      registerAPIService: false\n  override:\n    clusterAgent:\n      env: [{name: DD_EXTERNAL_METRICS_PROVIDER_ENABLE_DATADOGMETRIC_AUTOGEN, value: \"false\"}]\n[...]\n```\n\nNOTE: Using the Datadog Operator for this purpose requires version 1.8.0 of the operator or later.\n\n### Create a DatadogMetric object for each scaling query\n\nTo use the Datadog Cluster Agent to retrieve the query values from Datadog, first, create a [`DatadogMetric`](https://docs.datadoghq.com/containers/guide/cluster_agent_autoscaling_metrics/?tab=helm#create-the-datadogmetric-object) object with the query to drive your scaling events. You will need to add the `external-metrics.datadoghq.com/always-active: \"true\"` annotation, to ensure the Cluster Agent retrieves the query value. Example:\n\n```yaml\napiVersion: datadoghq.com/v1alpha1\nkind: DatadogMetric\nmetadata:\n  annotations:\n    external-metrics.datadoghq.com/always-active: \"true\"\n  name: nginx-hits\nspec:\n  query: sum:nginx.net.request_per_s{kube_deployment:nginx}\n```\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog Cluster Agent as proxy.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"true\"\n    datadogMetricName: \"nginx-hits\"\n    datadogMetricNamespace: \"default\"\n    targetValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    metricUnavailableValue: \"1.5\"\n    timeout: \"10s\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Values: true, false, Default: false, Optional)\n- `datadogMetricName` - The name of the `DatadogMetric` object to drive the scaling events.\n- `datadogMetricNamespace` - The namespace of the `DatadogMetric` object to drive the scaling events.\n- `targetValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n- `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n> 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as \"no data\" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA.\n\n### Authentication\n\nThe Datadog scaler with Cluster Agent supports one type of authentication - Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters in `TriggerAuthentication` as mentioned below:\n\n**Common to all authentication types**\n- `authMode` - The authentication mode to connect to the Cluster Agent. (Values: bearer, Default: bearer, Optional)\n- `datadogNamespace` - The namespace where the Datadog Cluster Agent is deployed.\n- `datadogMetricsService` - The service name for the Cluster Agent metrics server. To find the name of the service, check the available services in the Datadog namespace and look for the `*-cluster-agent-metrics*` name pattern.\n- `datadogMetricsServicePort` - The port of the service for the Cluster Agent Metrics API. (Default: 8443, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: true, false, Default: false, Optional)\n\n**Bearer authentication:**\n- `token` - The ServiceAccount token to connect to the Datadog Cluster Agent. The service account needs to have permissions to `get`, `watch`, and `list` all `external.metrics.k8s.io` resources. Instead of manually creating long-lived tokens stored in Secrets, it is recommended to use [Bound Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-tokens) via the `boundServiceAccountToken` parameter, which are more secure as they are time-bound and automatically rotated.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: datadog-config\n  namespace: my-project\ndata:\n  datadogNamespace:  # Required: namespace where the Datadog Cluster Agent is deployed\n  datadogMetricsService: # Required: Cluster Agent metrics server service name\n  unsafeSsl: # Optional: set to \"true\" to skip SSL certificate validation\n  authMode:  # Required: authentication mode (bearer)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: datadog-cluster-agent-creds\n  namespace: my-project\nspec:\n   boundServiceAccountToken:\n     - parameter: token\n       serviceAccountName: my-service-account # Required: service account with permissions to get, watch, list external.metrics.k8s.io\n  configMapTargetRef:\n    - parameter: datadogNamespace\n      name: datadog-config\n      key: datadogNamespace\n    - parameter: unsafeSsl\n      name: datadog-config\n      key: unsafeSsl\n    - parameter: authMode\n      name: datadog-config\n      key: authMode\n    - parameter: datadogMetricsService\n      name: datadog-config\n      key: datadogMetricsService\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx\n  maxReplicaCount: 3\n  minReplicaCount: 1\n  pollingInterval: 60\n  triggers:\n  - type: datadog\n    metadata:\n      useClusterAgentProxy: \"true\"\n      datadogMetricName: \"nginx-hits\"\n      datadogMetricNamespace: \"default\"\n      targetValue: \"2\"\n      type: \"global\"\n      timeout: \"10s\"\n    authenticationRef:\n      name: datadog-cluster-agent-creds\n```\n\n## Using the Datadog REST API\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog query, using the Datadog REST API.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    useClusterAgentProxy: \"false\"\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n    timeout: \"10s\"\n```\n\n**Parameter list:**\n\n- `useClusterAgentProxy` - Whether to use the Cluster Agent as proxy to get the query values. (Default: false)\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](../concepts/scaling-deployments#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n- `timeout` - Timeout (in a Duration string format) **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n> 💡 **NOTE:** Datadog may return HTTP 422 (Unprocessable Entity) or empty metric series. Both scenarios are treated as \"no data\" and will use `metricUnavailableValue` if set, otherwise an error is returned to the HPA.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n      # Optional: the HTTP timeout for this trigger\n      timeout: \"10s\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n### Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../reference/scaledobject-spec/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n### Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n#### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n#### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n### Cases of unexpected metrics value in DataDog API response\n\n#### Latest data point is unavailable\n\nBy default, Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n#### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.20/scalers/dynatrace.md",
    "content": "+++\ntitle = \"Dynatrace\"\navailability = \"2.15+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Dynatrace metric data points\"\ngo_file = \"dynatrace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `dynatrace` trigger that scales based on Dynatrace metric data points.\n\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      host: https://dummy-instance.live.dynatrace.com/\n      threshold: \"10\"\n      # Optional\n      activationThreshold: \"5\"\n      # Optional\n      metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n      # Optional\n      from: now-2d\n      # Optional\n      query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-2d'\n      # Optional\n      queryTimeoutSeconds: \"10\"\n      # Optional\n      queryPollingWait: \"1s\"\n      # Optional\n      queryPollingTries: \"5\"\n```\n\n**Parameter list:**\n\n- `host` - The Dynatrace instance to query against. (This value can be different when using `metricSelector` than when using `query`)\n- `metricSelector` - The metric selector query and any transformations that should be applied to it ([transformations docs](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/metric-selector)). (Optional, Mutually exclusive with `query`)\n\n  Some relevant aspects:\n    - The selector should focus on a **single metric and dimension**: if multiple are found, a warning is issued and only the first one is considered\n    - The metric data points should be aggregated to produce a single output value (e.g., using the [fold transformation](https://docs.dynatrace.com/docs/shortlink/api-metrics-v2-selector#fold)): if multiple values are found, only the first one is considered\n    - If you need to use the entity selector, do it through the `:filter` transformation in the metric selector\n- `from` - How far back the metric selector should consider when fetching data points. [syntax supported](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points#parameters). (Optional, default `now-2h`, i.e., the last 2 hours, This only applies when `metricSelector` is used; with `query`, the time range must be included within the query)\n- `query` - [DQL](https://docs.dynatrace.com/docs/discover-dynatrace/platform/grail/dynatrace-query-language) query to be executed. (Optional, Mutually exclusive with `metricSelector`)\n\n  Some relevant aspects:\n    - Query must return a single scalar named `r` that KEDA will use as metric, other fields will be ignored.\n    - KEDA will poll 5 times the value with a second between tries, so the query needs to have a result within that window.\n- `queryTimeoutSeconds` - Timeout in seconds passed to fetch data on Dynatrace side (Default: `10`, Optional, Only applies with `query`)\n- `queryPollingWait` - Time between result polling tries (Default: `1s`, Optional, Only applies with `query`)\n- `queryPollingTries` - Total polling tries (Default: `5`, Optional, Only applies with `query`)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Optional, default `0`, can be a float)\n\n> NOTE: Modifying the values of `queryPollingWait` or `queryPollingTries` can increase the response time and the HPA Controller can register timeouts because of this. If your query requires longer times, you should evaluate options like [caching metrics (`useCachedMetrics`)](./../reference/scaledobject-spec.md#triggers) in addition to these parameters.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure authentication for the `host` and `token` parameters.\n\n**Authentication:**\n\n- `host` - The Dynatrace instance to query against (This value can be different when using `metricSelector` than when using `query`)\n- `token` - The API key that will be leveraged to connect to Dynatrace and make requests. For `metricSelector`, token requires the `metrics.read` scope ([official documentation](https://docs.dynatrace.com/docs/dynatrace-api/basics/dynatrace-api-authentication)). For `query`, token **[has to be a platform token](https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients/platform-tokens)** with enough permissions for the table that you want to use (OIDC client isn't supported).\n\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5saXZlLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.live.dynatrace.com/\n  token: ZHQwczAxLlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s01.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        metricSelector: 'MyCustomEvent:filter(eq(\"someProperty\",\"someValue\")):count:splitBy(\"dt.entity.process_group\"):fold'\n        from: 'now-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n\n### DQL Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: dynatrace-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  host: aHR0cHM6Ly9kdW1teS1pbnN0YW5jZS5hcHBzLmR5bmF0cmFjZS5jb20v # base64 encoding of https://dummy-instance.apps.dynatrace.com/\n  token: ZHQwczE2LlNUMkVZNzJLUUlOTUg1NzRXTU5WSTdZTi5HM0RGUEJFSllNT0RJREFFWDQ1NE03WVdCVVZFRk9XS1BSVk1XRkFTUzY0TkZINTJQWDZCTkRWRkZNNTcyUlpN # base64 encoding of the dynatrace example api key dt0s16.ST2EY72KQINMH574WMNVI7YN.G3DFPBEJYMODIDAEX454M7YWBUVEFOWKPRVMWFASS64NFH52PX6BNDVFFM572RZM\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-dynatrace\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: token\n    name: dynatrace-secret\n    key: token\n  - parameter: host\n    name: dynatrace-secret\n    key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: dynatrace-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: dynatrace\n      metadata:\n        query: 'timeseries { r = max(`my-metric`, scalar: true) }, from:now()-30m'\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-dynatrace\n```\n### Troubleshooting & Tips\n\n#### Required Token Permissions for `query` Parameter\n\nWhen using the `query` parameter (DQL-based queries), your platform token must have **both** of the following scopes:\n\n- `storage:metrics:read`\n- `storage:buckets:read`\n\n> **Note:** This is different from `metricSelector`, which only requires `metrics.read`.\n\n#### Testing Your Query with Dynatrace Swagger UI\n\nYou can test your DQL query directly as your token using the Dynatrace Swagger UI before configuring KEDA:\n```\nhttps://<your-environment-id>.apps.dynatrace.com/platform/swagger-ui/index.html?urls.primaryName=Grail+-+DQL+Query#/Query%20Execution/query%3Aexecute\n```\n\nClick the **Authorize** button (top right) and enter your platform token to authenticate. This lets you validate your query and permissions before using them in KEDA.\n\n#### Example: Scaling Based on GCP Pub/Sub via Dynatrace\n\nIf your GCP project is onboarded into Dynatrace, you can scale based on Pub/Sub metrics using a DQL query like this:\n```yaml\ntriggers:\n  - type: dynatrace\n    metadata:\n      query: >-\n        timeseries value = max(cloud.gcp.pubsub_googleapis_com.subscription.num_unacked_messages_by_region, scalar:true),\n        filter: gcp.project.id == \"myproject\",\n        from: now()-5m\n        | fields value\n        | append [data record(value = 0.0)]\n        | summarize r = toDouble(max(value))\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on 'elasticsearch search template query' or 'elasticsearch query' result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query or [elasticsearch query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html).\n\nThe trigger always requires the following information, but requires either only searchTemplateName **or** only query:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      query: \"my-query\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `query` - The query to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `ignoreNullValues` - Set to `true` to ignore error when Null values are discovered. Set to `false`, the scaler will return error when Null values are discovered. (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Examples\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses the search template and `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `query`. In this example the transactions will be count that the application has to process based on APM.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        query: |\n          {\n            \"size\": 0,\n            \"query\": {\n              \"bool\": {\n                \"must\": [\n                  {\n                    \"term\": {\n                      \"service.name\": \"my-application\" }\n                  },\n                  {\n                    \"term\": {\n                      \"service.environment\": \"production\" }\n                  },\n                  {\n                    \"range\": {\n                      \"@timestamp\": {\n                        \"gte\": \"now-2m\",\n                        \"lte\": \"now-1m\"\n                      }\n                    }\n                  }\n                ]\n              }\n            },\n            \"aggs\": {\n              \"transaction_count\": {\n                \"cardinality\": {\n                  \"field\": \"transaction.id\" }\n              }\n            }\n          }\n        valueLocation: \"aggregations.transaction_count.value\"\n        targetValue: \"1000\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n        usernameFromEnv: <admin-user>  # Optional\n        passwordFromEnv: <admin-password> # Optional\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Password based authentication:**\n\n- `username` - Username for authentication. (Optional)\n- `password` - Password for authentication. (Optional)\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on Password auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  etcd-username: <your username>\n  etcd-password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-etcd-secrets\n      key: etcd-username\n    - parameter: password\n      name: keda-etcd-secrets\n      key: etcd-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsCertFile: /path/to/tls/cert.pem # Deprecated. https://github.com/kedacore/keda/issues/4549\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      unsafeSsl: false\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Extensibility\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    caCert : /path/to/tls/ca.pem\n    tlsClientCert: /path/to/tls/cert.pem\n    tlsClientKey: /path/to/tls/key.pem\n    enableTLS: false\n    unsafeSsl: false\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `enableTLS` - Allow a connection using TLS and use CAs already loaded by the Operator for validation. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\n- `caCert` - Certificate Authority (CA) certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientCert` - Client certificate to use for the GRPC connection to authenticate with. (Optional)\n- `tlsClientKey` - Client private key to use for the GRPC connection to authenticate with. (Optional)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n\nHere is an example of external scaler with certificates\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: certificate\ndata:\n  ca.crt: \"YOUR_CA_IN_SECRET\"\n  tls.crt: \"YOUR_CERTIFICATE_IN_SECRET\"\n  tls.key: \"YOUR_KEY_IN_SECRET\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth\nspec:\n  secretTargetRef:\n  - parameter: caCert\n    name: certificate\n    key: ca.crt\n  - parameter: tlsClientCert\n    name: certificate\n    key: tls.crt\n  - parameter: tlsClientKey\n    name: certificate\n    key: tls.key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: external-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      metricType: mymetric\n      scalerAddress: mydomain.com:443\n      extraKey: \"demo\"\n    authenticationRef:\n      name: keda-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/forgejo.md",
    "content": "+++\ntitle = \"Forgejo\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"CI/CD\"\ndescription = \"Scale applications based on pending jobs on Forgejo repository.\"\ngo_file = \"forgejo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `forgejo-runner` trigger for Forgejo Actions. It scales based on the amount of jobs pending in given runner labels.\n\n```yaml\ntriggers:\n  - type: forgejo-runner\n    metadata:\n      # Required: the name of the registered runner \n      name: \"forgejo-runner-ubuntu\"\n      # Required: the url of the forgejo instance \n      address: \"http://localhost:3000\"\n      # Optional: Scope of the jobs to check, global is the default one and will get all the jobs in the instance with the defined labels\n      global: \"true\" \n      # Optional: User to set as a scope, global should be false, if no repo is set will get all the pending jobs for the user\n      owner: \"cobak\"\n      # Optional: Repository level scope\n      repo: \"my-repo\"\n      # Required: Will get the jobs with match with this labels\n      labels: \"ubuntu-latest\"\n```\n\n**Parameter list:**\n\n- `name` - Name of the registered runner.\n- `address` - Url of the forgejo instance.\n- `global` - Scope of the jobs to check. (Values: `true`, `false`, Default: `true`, Optional, Mutually exclusive with `owner` and `repo`)\n- `owner` - User to set as a scope. (Optional, Mutually exclusive with `global` and `repo`)\n- `repo` - User to set as a scope. (Optional, Mutually exclusive with `global` and `owner`)\n- `labels` - Labels to match the job with.\n\n\n### Authentication Parameters\n\n- `token` - Required token to connect to forgejo instance.\n\n### Options on how to set the scope (global, user, repo)\n\n1. If you set owner and repo KEDA forgejo scaler will retrieve jobs from that repository:\n   ```\n   owner: \"username\"\n   repo: \"my_repo\"\n   ```\n2. If you set the organization will retrieve the organization jobs:\n   ```\n   org: \"my_org\"\n   ```\n3. If you set global: true will retrieve all the jobs from the instance\n   ```\n   global: \"true\"\n   ```\n4. And if you don't set any of this optional fields will retrieve the jobs from the user who creates the token \n\n## Configuration \n\n### Registering runners and binding config with autoscalers\n\nTo match job endpoints with job execution, we need to pre-register a runner, save the generated JSON file as a ConfigMap, and share it with the autoscaler. review the different ways to register a runner [here](https://forgejo.org/docs/latest/admin/runner-installation/#standard-registration), select the desired scope (user, repository or global) and create the corresponding JSON file. \n\nAutoscaler definition and runner registration should match to work as expected.\n\nCreate a .runner file and a registration file with this commands, and set the output in a configmap.\n\n```shell\ndocker run -v /var/run/docker.sock:/var/run/docker.sock  -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner register --no-interactive --token xxxx --name runner --instance http://localhost:3000/ --labels ubuntu-20:docker://node:20-bookworm,docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\ndocker run -v /var/run/docker.sock:/var/run/docker.sock  -v $PWD:/data --rm code.forgejo.org/forgejo/runner:6.3.1 forgejo-runner generate-config > registration.yaml \n```\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: runner-config\n  namespace: runners\ndata:\n  .runner: |\n    {\n        \"WARNING\": \"This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.\",\n        \"id\": 3,\n        \"uuid\": \"be6b5260-e73f-4e21-af84-8e205dbaaacd\",\n        \"name\": \"runner\",\n        \"token\": \"<global-runner-token>\",\n        \"address\": \"http://localhost:3000/\",\n        \"labels\": [\n            \"ubuntu-20:docker://node:20-bookworm\",\n            \"docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\"\n        ]\n      }\n\n---\n\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: runner-registration\n  namespace: runners\ndata:\n  registration.yaml: |\n    log:\n      # The level of logging, can be trace, debug, info, warn, error, fatal\n      level: info\n      # The level of logging for jobs, can be trace, debug, info, earn, error, fatal\n      job_level: info\n\n    runner:\n      # Where to store the registration result.\n      file: /data/.runner\n      # Execute how many tasks concurrently at the same time.\n      capacity: 1\n      # Extra environment variables to run jobs.\n      envs:\n        DOCKER_HOST: tcp://localhost:2376\n        DOCKER_TLS_VERIFY: 1\n        DOCKER_CERT_PATH: /certs/client\n      # Extra environment variables to run jobs from a file.\n      # It will be ignored if it's empty or the file doesn't exist.\n      env_file: .env\n      # The timeout for a job to be finished.\n      # Please note that the Forgejo instance also has a timeout (3h by default) for the job.\n      # So the job could be stopped by the Forgejo instance if it's timeout is shorter than this.\n      timeout: 3h\n      # The timeout for the runner to wait for running jobs to finish when\n      # shutting down because a TERM or INT signal has been received.  Any\n      # running jobs that haven't finished after this timeout will be\n      # cancelled.\n      # If unset or zero the jobs will be cancelled immediately.\n      shutdown_timeout: 3h\n      # Whether skip verifying the TLS certificate of the instance.\n      insecure: false\n      # The timeout for fetching the job from the Forgejo instance.\n      fetch_timeout: 5s\n      # The interval for fetching the job from the Forgejo instance.\n      fetch_interval: 2s\n      # The interval for reporting the job status and logs to the Forgejo instance.\n      report_interval: 1s\n      # The labels of a runner are used to determine which jobs the runner can run, and how to run them.\n      # Like: [\"macos-arm64:host\", \"ubuntu-latest:docker://node:20-bookworm\", \"ubuntu-22.04:docker://node:20-bookworm\"]\n      # If it's empty when registering, it will ask for inputting labels.\n      # If it's empty when executing the `daemon`, it will use labels in the `.runner` file.\n      labels:\n        - ubuntu-20:docker://node:20-bookworm\n        - docker:docker://ghcr.io/catthehacker/ubuntu:act-latest\n\n    cache:\n      # Enable cache server to use actions/cache.\n      enabled: true\n      # The directory to store the cache data.\n      # If it's empty, the cache data will be stored in $HOME/.cache/actcache.\n      dir: \"\"\n      # The host of the cache server.\n      # It's not for the address to listen, but the address to connect from job containers.\n      # So 0.0.0.0 is a bad choice, leave it empty to detect automatically.\n      host: \"\"\n      # The port of the cache server.\n      # 0 means to use a random available port.\n      port: 0\n      # The port of the cache proxy.\n      # 0 means to use a random available port.\n      proxy_port: 0\n      # The external cache server URL. Valid only when enable is true.\n      # If it's specified, it will be used to set the ACTIONS_CACHE_URL environment variable. The URL should generally end with \"/\".\n      # Otherwise it will be set to the the URL of the internal cache server.\n      external_server: \"\"\n      # The shared cache secret. When communicating with a cache server, the runner uses this secret to verify the authenticity of the cache requests.\n      # When using an external cache server it is required to set the same secret for the runner and the cache server.\n      secret: \"\"\n      # Overrides the ACTIONS_CACHE_URL passed to workflow containers. This should only be used if the runner host is not reachable from the\n      # workflow containers, and requires further setup.\n      actions_cache_url_override: \"\"\n\n    container:\n      # Specifies the network to which the container will connect.\n      # Could be host, bridge or the name of a custom network.\n      # If it's empty, create a network automatically.\n      network: host\n      # Whether to create networks with IPv6 enabled. Requires the Docker daemon to be set up accordingly.\n      # Only takes effect if \"network\" is set to \"\".\n      enable_ipv6: false\n      # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker).\n      privileged: false\n      # And other options to be used when the container is started (eg, --add-host=my.forgejo.url:host-gateway).\n      options: -v /certs/client:/certs/client\n      # The parent directory of a job's working directory.\n      # If it's empty, /workspace will be used.\n      workdir_parent:\n      # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob\n      # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted.\n      # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to:\n      # valid_volumes:\n      #   - data\n      #   - /src/*.json\n      # If you want to allow any volume, please use the following configuration:\n      # valid_volumes:\n      #   - '**'\n      valid_volumes:\n        - /certs/client\n      # overrides the docker client host with the specified one.\n      # If \"-\" or \"\", an available docker host will automatically be found.\n      # If \"automount\", an available docker host will automatically be found and mounted in the job container (e.g. /var/run/docker.sock).\n      # Otherwise the specified docker host will be used and an error will be returned if it doesn't work.\n      docker_host: \"-\"\n      # Pull docker image(s) even if already present\n      force_pull: false\n      # Rebuild local docker image(s) even if already present\n      force_rebuild: false\n\n    host:\n      # The parent directory of a job's working directory.\n      # If it's empty, $HOME/.cache/act/ will be used.\n      workdir_parent:\n\n```\n\n### Create a token on forgejo\n\nThe autoscaler will continuously fetch new waiting jobs from Forgejo, so it requires a properly configured token with the appropriate permissions. Navigate to **Forgejo > User settings > Applications > Access Tokens** and generate a new token. This token will be used by the autoscaler\n\n### Configuring KEDA Autoscaler\n\nCreate a new custom resource with the required parameters and custom fields based on the scope chosen during runner registration. For example, set `global=\"true\"` for global runners or specify `repo=xxx` and `owner=xxx` for repository level runners.\n\nChoose the runner image you want to use (>6.1 of forgejo runner releases) or a custom one with `--one-job` command. \n\nApply the new custom resource to your cluster.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: forgejo-runner-secret\n  namespace: runners\ndata:\n  token: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: forgejo-runner-creds\n  namespace: runners\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: forgejo-runner-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  labels:\n    app: forgejo-runner\n  name: upload-platform-forgejo-runner\n  namespace: runners\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: forgejo-runner\n      spec:\n        volumes:\n          - name: runner-data\n            emptyDir: {}\n          - name: runner-config\n            configMap:\n              name: upload-platform-runner-config\n          - name: runner-registration\n            configMap:\n              name: upload-platform-runner-registration\n          - name: docker-certs\n            emptyDir: {}\n        restartPolicy: Never\n        shareProcessNamespace: true\n        containers:\n          - name: runner\n            image: code.forgejo.org/forgejo/runner:6.3.1\n            command:\n              - sh\n              - -c\n              - |\n                while ! nc -z localhost 2376 </dev/null; do \n                  echo 'waiting for docker daemon...'\n                  sleep 5\n                done\n\n                cp /config/.runner /data/.runner\n\n                exec forgejo-runner -c /registration/registration.yaml one-job\n            securityContext:\n              privileged: true\n              runAsUser: 0\n            env:\n              - name: DOCKER_HOST\n                value: tcp://localhost:2376\n              - name: DOCKER_CERT_PATH\n                value: /certs/client\n              - name: DOCKER_TLS_VERIFY\n                value: \"1\"\n            volumeMounts:\n              - name: docker-certs\n                mountPath: /certs\n              - name: runner-data\n                mountPath: /data\n              - name: runner-registration\n                mountPath: /registration\n                readOnly: false\n              - name: runner-config\n                mountPath: /config\n                readOnly: false\n          - name: daemon\n            image: docker:27.4.1-dind\n            command:\n              - sh\n              - -c\n              - |\n                dockerd-entrypoint.sh 2>&1 &\n\n                while kill -0 7 2>/dev/null\n                  do sleep 10 \n                  echo \"watching main job execution\"\n                done;\n\n                sleep 10\n\n                echo \"main container exited, stopping dind\"\n                exit 0\n            env:\n              - name: DOCKER_TLS_CERTDIR\n                value: /certs\n              - name: DOCKER_HOST\n                value: tcp://0.0.0.0:2376\n            securityContext:\n              privileged: true\n              runAsUser: 0\n            volumeMounts:\n              - name: docker-certs\n                mountPath: /certs\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n    - type: forgejo-runner\n      metadata:\n        name: \"runner\"\n        address: \"http://localhost:3000/\"\n        global: \"true\"\n        labels: \"ubuntu-20,docker\"\n      authenticationRef:\n        name: forgejo-runner-creds\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/gcp-cloud-tasks.md",
    "content": "+++\ntitle = \"Google Cloud Platform Cloud Tasks\"\navailability = \"v2.12+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Cloud Tasks.\"\ngo_file = \"gcp_cloud_tasks_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-cloudtasks` trigger for Google Cloud Platform Cloud Tasks.\n\n```yaml\ntriggers:\n- type: gcp-cloudtasks\n  metadata:\n    value: \"5\" # Optional - Default is 100\n    activationValue: \"10.5\" # Optional - Default is 0\n    filterDuration: '1' # Optional - Default is 2\n    queueName: \"myqueue\" # Required\n    projectID: \"myproject\" # Required, the project where the queue resides\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Cloud Tasks trigger allows you to scale based on the number of tasks queued in you queue.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Cloud Task queue.\n\n- `value` - Target value for the scaler. (Default: `100`, Optional, This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional, This value can be a float)\n- `queueName` defines the queue that should be monitored.\n- `projectID` defines the GCP project where the queue that should be monitored resides.\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\n  namespace: keda-cloudtasks-test\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: cloudtasks-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cloudtasks-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-cloudtasks-go\n  triggers:\n  - type: gcp-cloudtasks\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      activationValue: \"5\"\n      projectID: \"myproject\" # Required\n      queueName: \"myqueue\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # The 'subscriptionSize' setting is DEPRECATED and will be removed in v2.20 - Use 'mode' and 'value' instead\" \n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    aggregation: \"sum\" # Optional - Only meaningful for distribution-valued metrics\n    value: \"5.5\" # Optional - Default is 10\n    valueIfNull: '0.0' # Optional - Default is \"\"\n    activationValue: \"10.5\" # Optional - Default is 0\n    timeHorizon: \"1m\" # Optional - Default is 2m and with aggregation 5m\n    # Exactly one of the subscription or topic name options is required\n    subscriptionName: \"mysubscription\"\n    subscriptionNameFromEnv: \"MY_SUBSCRIPTION_FROM_ENV\"\n    topicName: \"mytopic\"\n    topicNameFromEnv: \"MY_TOPIC_FROM_ENV\"\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on any metrics from your Pub/Sub subscription or topic, such as number of messages or oldest unacked message age, etc.\n\n- `credentialsFromEnv` - This property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `mode` - The metric used to scale your workload. It's the `PascalCase` of the official metric name. For example, if you are going to leverage the metric `subscription/pull_request_count`, you will fill the value as `PullRequestCount`. Please refer to https://cloud.google.com/monitoring/api/metrics_gcp#gcp-pubsub. All metrics starting with `subscription/` and `topic/` are supported. (Default: `SubscriptionSize`, aka `NumUndeliveredMessages`)\n\n- `aggregation` - The aggregation function used to aggregate the metric. (Values: mean, median, variance, stddev, sum, count, percentileX (X: an integer in the range 0 to 100), Required for metrics with value type `DISTRIBUTION`)\n\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n- `timeHorizon` - Time range for which you want to retrieve the metrics. (Default: `2m` and Default with aggregation field: `5m`)\n\n- `valueIfNull` - Value returned if request returns no timeseries.(Default: `\"\"`, Optional, This value can be a float) \n\n- `subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n  - Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\n- `subscriptionNameFromEnv` - The name of an environment variable on the scale target that holds the subscription name. The resolved name is processed the same as `subscriptionName`.\n\n- `topicName` defines the topic that should be monitored. Similar to `susbcriptionName`, you can use different formulas:\n  - Just the topic name, in which case you will reference a topic from the current project or the one specified in the credentials file used.\n  - Use the full link provided by Google, so that you can reference a topic that is hosted in another project Eg: `projects/myproject/topics/mytopic`.\n\n- `topicNameFromEnv` - The name of an environment variable on the scale target that holds the topic name. The resolved name is processed the same as `topicName`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using distribution-valued metric and aggregation\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      # Example: https://cloud.google.com/pubsub/docs/monitoring#monitoring_message_throughput_2\n      mode: \"MessageSizes\"\n      aggregation: \"count\" # Calculate count of messages being published\n      value: \"50\"\n      topicName: \"mytopic\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n> 💡 **WARNING:** This scaler is deprecated and won't receive any modification. [Read more about it here](../../../blog/2025-09-15-gcp-deprecations.md).\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    valueIfNull: '0.0' #Optional - Default is \"\"\n    filterDuration: '1' # Optional - Default is 2\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `valueIfNull` - Value return if request return no timeseries.(Default: `\"\"`, Optional, This value can be a float)\n- `filterDuration` - Duration (in minutes) for filtering metrics. (Default: `2`)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, rate, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/github-runner.md",
    "content": "+++\ntitle = \"Github Runner Scaler\"\navailability = \"v2.10+\"\nmaintainer = \"GitHub\"\ncategory = \"CI/CD\"\ndescription = \"Scale GitHub Runners based on the number of queued jobs in GitHub Actions\"\ngo_file = \"github_runner_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `github-runner-scaler` trigger that scales based on queued jobs in GitHub Actions.\n\n```yaml\ntriggers:\n  - type: github-runner\n    metadata:\n      # Optional: The URL of the GitHub API, defaults to https://api.github.com\n      githubApiURL: \"https://api.github.com\"\n      # Required: The owner of the GitHub repository, or the organization that owns the repository\n      owner: \"{owner}\"\n      # Required: The scope of the runner, can be either \"org\" (organisation), \"ent\" (enterprise) or \"repo\" (repository)\n      runnerScope: \"{runnerScope}\"\n      # Optional: The list of repositories to scale, separated by comma\n      repos: \"{repos}\"\n      # Optional: The list of runner labels to scale on, separated by comma\n      labels: \"{labels}\"\n      # Optional: Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\", defaults to \"false\" (scale on default runner labels)\n      noDefaultLabels: \"{noDefaultLabels}\"\n      # Optional: When enabled unlabeled jobs will not match unlabeled runners. Can be either \"true\" or \"false\", defaults to \"false\"\n      matchUnlabeledJobsWithUnlabeledRunners: \"{matchUnlabeledJobsWithUnlabeledRunners}\"\n      # Optional: Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. Can be either \"true\" or \"false\", defaults to \"false\"\n      enableEtags: \"{enableEtags}\"\n      # Optional: The target number of queued jobs to scale on\n      targetWorkflowQueueLength: \"1\" # Default 1\n      # Optional: The name of the application ID from the GitHub App\n      applicationID: \"{applicatonID}\"\n      # Optional: The name of the installation ID from the GitHub App once installed into Org or repo.\n      installationID: \"{installationID}\"      \n    authenticationRef:\n      name: personalAccessToken or appKey triggerAuthentication Reference\n```\n\n**Parameter list:**\n\n- `githubApiURL` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `owner` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScope` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `repos` - The list of repositories to scale, separated by comma. (Optional)\n- `labels` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabels` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"). (Values: `true`,`false`, Default: \"false\", Optional)\n- `matchUnlabeledJobsWithUnlabeledRunners` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: \"false\", Optional)\n- `enableEtags` -  Enable etag headers to make conditional requests to the Github API. Requests do not count against your rate limit if a 304 response is returned. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLength` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationID` - The name of the application ID from the GitHub App. (Optional, Required if installationID set)\n- `installationID` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional, Required if applicationID set)\n\n*Parameters from Environment Variables*\n\nYou can access each parameter from above using environment variables. When you specify the parameter in metadata with a suffix of `FromEnv`, \nthe scaler will use the value from the environment variable. The environment variable must be available to the manifest. e.g. `labelsFromEnv: \"RUNNER_LABELS\"` will use the environment variable `RUNNER_LABELS` as the source fo the `labels` parameter.\n\n- `githubApiURLFromEnv` - The URL of the GitHub API, defaults to https://api.github.com. You should only need to modify this if you have your own GitHub Appliance. (Optional)\n- `ownerFromEnv` - The owner of the GitHub repository, or the organization that owns the repository. (Required)\n- `runnerScopeFromEnv` - The scope of the runner, can be either \"org\", \"ent\" or \"repo\". (Required)\n- `reposFromEnv` - The list of repositories to scale, separated by comma. (Optional)\n- `labelsFromEnv` - The list of runner labels to scale on, separated by comma. (Optional)\n- `noDefaultLabelsFromEnv` - Not scale on default runner labels (\"self-hosted\", \"linux\", \"x64\"), can be either \"true\" or \"false\". (Optional)\n- `matchUnlabeledJobsWithUnlabeledRunnersFromEnv` - When enabled unlabeled jobs will not match unlabeled runners. (Values: `true`,`false`, Default: \"false\", Optional)\n- `targetWorkflowQueueLengthFromEnv` - The target number of queued jobs to scale on. (Optional, Default: 1)\n- `applicationIDFromEnv` - The name of the application ID from the GitHub App. (Optional) (Required if installationID set)\n- `installationIDFromEnv` - The name of the installation ID from the GitHub App once installed into Org or repo. (Optional) (Required if applicationID set)\n\n### Authentication Parameters\n\nYou authenticate with GitHub using a Personal Access Token or a GitHub App private key via `TriggerAuthentication` configuration.\n\n**Token or Key Authentication:**\n\n- `personalAccessToken` - The Personal Access Token (PAT) for GitHub from your user. (Optional, Required if GitHub App not used)\n- `appKey` - The private key for the GitHub App. This is the contents of the `.pem` file you downloaded when you created the GitHub App. (Optional, Required if applicationID set)\n\n### Setting up the GitHub App\n\nYou can use the GitHub App to authenticate with GitHub. This is useful if you want a more secure method of authentication with higher rate limits.\n\n1. Create a GitHub App in your organization or repository. ([docs](https://docs.github.com/en/developers/apps/creating-a-github-app))\n2. Make a note of the Application ID. You will need these to configure the scaler.\n3. Disable Webhooks on your GitHub App.\n4. Set the permissions for your GitHub App. The following permissions are required:\n    - **Repository permissions**\n        - Actions - Read-only\n        - Administration - Read & Write\n        - Metadata - Read-only\n    - **Organization permissions**\n        - Actions - Read-only\n        - Metadata - Read-only\n        - Self-hosted Runners - Read & write\n5. Download the private key for the GitHub App. ([docs](https://docs.github.com/en/developers/apps/authenticating-with-github-apps#generating-a-private-key))\n6. Install the GitHub App on your organization or repository. ([docs](https://docs.github.com/en/developers/apps/installing-github-apps))\n7. Make a note of the Installation ID. You will need these to configure the scaler.\n\n### How does it work?\n\nThe scaler will query the GitHub API to get the number of queued jobs in the specified repositories, subject to filters. If the number of queued jobs is equal to or greater than the `targetWorkflowQueueLength`,  the scaler will scale up.\n\nWe provide various options to have granular control over what runners to scale:\n- **Repository Filtering** - If no `repos` are specified, the scaler will query all repositories in the specified `owner`. This is useful if you want to scale on all repositories in an organization, but will result in a lot of API calls which can affect the Rate Limit. By setting `enableEtags` to `true` this can reduce the impact on the rate limit as this would make [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API. In this case if the request response is `304: Not modified` this will not count against the rate limit and the previously found repositories will be used.\n- **Label-based Filtering** - The `labels` parameter is used to filter the runners that the scaler will scale. It uses the minimum applicable label for the runner. For example, if you have a runner with the labels `golang` and `helm`, and you specify `helm` in the `labels` field on the GitHub Action, the scaler will scale up that runner. By default the scaler will always scale on default labels (`self-hosted`, `linux`, `x64`) in addition to the ones defined in `labels` parameter, scaling on default labels can be disabled by setting `noDefaultLabels` parameter to `true`.\n\n**API Query Chain**\n\nThe scaler will query the GitHub API in the following order:\n\n- If no repos are specified: Get the list of repos for the specified owner.\n- For each repo: Get the list of workflows runs in the repo.\n- For each queued workflow run: Get the list of jobs in the queued workflow run.\n- For each job: if the scaler matches, increment the queue length for that scaler.\n\n**Notes on Rate Limits**\n\nGitHub Documentation on Rate Limiting [https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting](https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28#rate-limiting)\n\n| Authentication Method | Rate Limit (per hour) | Notes |\n|---|---|---|\n| Personal Access Token | 5000 | Standard rate limit |\n| GitHub App | 15000 | Higher rate limit |\n| Hosted Appliance | Unlimited | No rate limits apply |\n\nExample: The GitHub API has a rate limit of standard 5000 requests per hour. By default the scaler will make 1 request per repository to get the list of workflows,\nand 1 request per queued workflow to get the list of jobs. If you have 100 repositories, and 10 queued workflows (across all those repos), the scaler will make 110 requests per scaler check (default: 30 secs). This is 3.6% of the hourly rate limit per 30 seconds.\n\nCareful design of how you design your repository request layout and configure the scaler can help reduce the number of API calls. Here are some recommendations:\n\n- Using the `repos` parameter as opposed to just `owner` means that the Github API isn't queried to get a list of repositories.\n- Setting `enableEtags` to `true` can reduce the rate limit consumption, as this makes [conditional requests](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#use-conditional-requests-if-appropriate) against the Github API by passing the Etag of the last request to the URL, if a `304: Not modified` response is returned, this will not count against the rate limit. In this case the scaler will use the results from the last query to the URL where the response was `200: Success`.\n\nThe github scaler [handles rate limit errors appropriately](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2026-03-10#handle-rate-limit-errors-appropriately) by waiting until X-RateLimit-Reset or Retry-After times until the github API is queried when rate limited. During this time it will return the cached queue length which is updated with each successful request. \n\n**Fine-Tuning**\n\nThe current GitHub API design does not facilitate determining the number of pending jobs efficiently because it requires making many API calls to get an accurate estimate which increases the risk of reaching rate limits. So, there will be a trade off between lower scaler response times and staying within API rate limits. However, users have the flexibility to configure this scaler based on their specific uses cases by changing certain parameters.\n\nFor example, the scaler response time and bandwidth can be fine-tuned by adjusting the `pollingInterval` parameter. In theory, setting `pollingInterval` to `1` second, could result in starting up to 600,000 (100 runs x 100 jobs x 60 seconds) runners per minute for each repository (assuming eligible pending jobs are found). However, having so many pending jobs and setting `pollingInterval` to `1` results in at least 6,000 calls (100 runs * 60 seconds), reaching the API rate limit very quickly.\n\n*Starting KEDA version 2.17, this scaler can fetch up to 100 workflow runs per repository and 100 jobs per run during each polling cycle. Previous versions can fetch only 30 workflow runs per repository and 30 jobs per run during each polling cycle. More details are available on this [thread](https://github.com/kedacore/keda/pull/6519).*\n\nAt the moment, there's no elegant way to overcome this limit for this particular scaler, unless GitHub introduces a new API or enhances existing ones to allow fetching pending jobs filtered by labels and status in a single call.\n\n**References**\n\nGitHub's self-hosted runner documentation: [https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners)\n\nmyoung34's excellent worker on containerised runners: [https://github.com/myoung34/docker-github-actions-runner](https://github.com/myoung34/docker-github-actions-runner)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: github-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: github-runner-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: gitrunner-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: github-runner\n    metadata:\n      githubApiURL: \"https://api.github.com\"\n      owner: \"kedacore\"\n      runnerScope: \"repo\"\n      repos: \"keda,keda-docs\"\n      labels: \"golang,helm\"\n      targetWorkflowQueueLength: \"1\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nAlternate example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n    authenticationRef:\n     name: github-trigger-auth\n```\nGitHub App example using ScaledJobs and using myoung34's work on containerised runners:\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: github-auth\ndata:\n  appKey: <encoded PEM certificate from GitHub App>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: github-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: appKey\n      name: github-auth\n      key: appKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: scaledjob-github-runner\n  namespace: github-runner\nspec:\n  jobTargetRef:\n    template:\n      metadata:\n        labels:\n          app: scaledjob-github-runner\n      spec:\n        containers:\n        - name: scaledjob-github-runner\n          image: myoung34/github-runner:2.302.1-ubuntu-focal\n          imagePullPolicy: Always\n          env:\n          - name: EPHEMERAL\n            value: \"true\"\n          - name: DISABLE_RUNNER_UPDATE\n            value: \"true\"\n          - name: REPO_URL\n            value: \"https://github.com/OWNER/REPONAME\"\n          - name: RUNNER_SCOPE\n            value: \"repo\"\n          - name: LABELS\n            value: \"my-label\"\n          - name: ACCESS_TOKEN\n            valueFrom:\n              secretKeyRef:\n                name: {{.SecretName}}\n                key: personalAccessToken\n        restartPolicy: Never\n  minReplicaCount: 0\n  maxReplicaCount: 20\n  pollingInterval: 30\n  triggers:\n  - type: github-runner\n    metadata:\n      owner: OWNER\n      repos: REPONAME(S)\n      labelsFromEnv: \"LABELS\"\n      runnerScopeFromEnv: \"RUNNER_SCOPE\"\n      applicationID: \"1234\"\n      installationID: \"5678\"\n    authenticationRef:\n     name: github-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric. The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float) (**The 'minMetricValue' setting is DEPRECATED and will be removed in v2.20 - Use 'activationTargetMetricValue' instead**)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueName: <queue-name> # REQUIRED - Your queue name\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n    unsafeSsl: \"false\" # OPTIONAL - Used for skipping certificate check when having self-signed certs 'true'. Default: false\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueName` (or `queueNames`) - Name of the queue. It supports multiple queues separated by a comma character ( `,` ).\n- `operation` - Operation that will be applied to compute the number of messages. Either `max` (default), `sum`, or `avg`. (Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `20`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\nExample with Basic Auth\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n        usernameFromEnv: <admin-user> # OPTIONAL - Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # OPTIONAL - Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n\nExample with Basic Auth and TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n  cert: <your tls.crt>\n  key: <your tls.key>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueName: <queue-name> # REQUIRED - Your queue name\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 20 messages\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n    - parameter: cert\n      name: keda-ibmmq-secret\n      key: cert\n    - parameter: key\n      name: keda-ibmmq-secret\n      key: key\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org # Required for InfluxDB v2.x, optional for InfluxDB v3.x\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      metricKey: 'mymetric' # Required for Influx v3. Ignored for v2. See details in \"Parameter List\" section\n      queryType: 'InfluxQL' # Required for Influx v3. Ignored for v2. See details in \"Parameter List\" section\n      influxVersion: '2' # Optional: Defaults to 2.\n      database: 'some-influx-db' # Required for Influx v3\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc (Optional, Required if `influxVersion: '2'`).\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `influxVersion` - Specifies the version of InfluxDB being used. (Values: `2`, `3`, Default: `2`, Optional)\n- `database` - The name of the InfluxDB database to query. Required for InfluxDB v3.x. (Optional for InfluxDB v2.x)\n- `metricKey` - The name of the metric to be used for scaling decisions. This is required for InfluxDB v3.x and ignored for InfluxDB v2.x. It is used to identify the metric in the query results. For a `query` of `SELECT mean(\"mymetric\") AS \"metric_name\" FROM...` use `metricKey: 'metric_name'`. (Optional, Required if `influxVersion: '3'`)\n- `queryType` - Specifies the type of query being used. For InfluxDB v3.x, this can be either `InfluxQL` or `FlightSQL`. For InfluxDB v2.x, this parameter is ignored. (Values: `InfluxQL`, `FlightSQL`, Default: `InfluxQL`, Optional)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example (InfluxDB v2)\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` (v2) scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n\n### Example (InfluxDB v3)\n\nBelow is a similar example for Influx v3 using an `InfluxQL` query.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        database: 'my-metrics-db'\n        influxVersion: '3'\n        queryType: 'InfluxQL'\n        metricKey: 'mean'\n        thresholdValue: '2'\n        activationThresholdValue: '10'\n        query: |\n          SELECT mean(\"water_level\") FROM \"h2o_feet\"\n          GROUP BY time(5m)\n          ORDER BY time DESC LIMIT 1;\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/kubernetes-resource.md",
    "content": "+++\ntitle = \"Kubernetes Resource\"\navailability = \"v2.19+\"\nmaintainer = \"Community\"\ncategory = \"Kubernetes\"\ndescription = \"Scale applications based on values in Kubernetes ConfigMaps or Secrets\"\ngo_file = \"kubernetes_resource_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `kubernetes-resource` trigger that scales based on a value found in a Kubernetes ConfigMap or Secret.\n\nThis scaler allows users to scale workloads by extracting values from Kubernetes resources, supporting number, JSON, and YAML formats.\n\nHere is an example of trigger configuration using kubernetes-resource scaler:\n\n```yaml\ntriggers:\n- type: kubernetes-resource\n  metadata:\n    resourceKind: \"Secret\"\n    resourceName: \"my-secret\"\n    key: \"data\"\n    format: \"json\"\n    valueLocation: \"count\"\n    valueType: \"float64\"\n    targetValue: \"10\"\n    activationTargetValue: \"5\"\n```\n\n**Parameter list:**\n\n- `resourceKind` - Type of Kubernetes resource to read from. Supported values: `ConfigMap`, `Secret` (Required)\n- `resourceName` - Name of the resource to read. (Required)\n- `key` - Key in the ConfigMap's `data` field or Secret's `data` field to read from. The value at this key is retrieved as a string. (Required)\n- `format` - Format of the string value retrieved from `key`. Supported values: `number`, `json`, `yaml`. (Default: `number`, Optional)\n  - `number` - The string value is parsed directly as a number\n  - `json` - The string value is a JSON document, and `valueLocation` extracts a field from it\n  - `yaml` - The string value is a YAML document, and `valueLocation` extracts a field from it\n- `valueLocation` - Path to extract the metric value from the JSON or YAML content retrieved from `key`. Required for `json` and `yaml` formats. Not used for `number` format. For `json`, use [GJSON path notation](https://github.com/tidwall/gjson#path-syntax). For `yaml`, use dot-separated path (e.g., `foo.bar.count`). (Optional)\n- `valueType` - Type of value to extract. Supported values: `float64`, `int64`, `quantity`. (Default: `float64`, Optional)\n  - `float64` - Floating point number. For JSON format, accepts both numbers and quantity strings.\n  - `int64` - Integer number. For JSON format, only accepts integer numbers (decimal values are truncated). For `number` format, the string must be parseable as an integer.\n  - `quantity` - Kubernetes quantity (e.g., \"100m\", \"1Gi\"). For JSON/YAML formats, parses string values as quantities. For JSON format, also accepts raw numbers.\n- `targetValue` - Target value to scale on. When the extracted value is equal or higher, KEDA will scale out. (Required)\n- `activationTargetValue` - Value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNo authentication parameters are required. The scaler uses the permissions of the KEDA operator to access resources in the same namespace.\n\n### Example\n\nHere is a full example of scaled object definition using Kubernetes Resource trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: k8s-resource-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 10\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"my-configmap\"\n        key: \"metrics\"\n        format: \"yaml\"\n        valueLocation: \"count\"\n        valueType: \"int64\"\n        targetValue: \"10\"\n```\n\nAssuming the ConfigMap contains:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: my-configmap\n  namespace: keda\ndata:\n  metrics: |\n    count: 12\n    other: value\n```\n\nThe scaler will extract the value at `count` from the YAML data in the `metrics` key and use it for scaling decisions.\n\n> 💡 **NOTE:** \n> - The `valueType` parameter controls how values are parsed. For `int64`, decimal values in JSON are truncated to integers.\n> - For `json` format, use GJSON path syntax. For `yaml` format, use dot-separated path. For `number` format, the value at the key is used directly.\n> - For YAML format, the `valueType` determines how the extracted value is converted, regardless of whether the value is a string or a native YAML number. For example, if `valueType` is set to `int64`, the value will be converted to an integer; if set to `quantity`, it will be parsed as a Kubernetes quantity. By default, numeric YAML values are converted to float64 unless a different `valueType` is specified.\n\n### Additional Examples\n\n#### Example 1: Number Format (Direct Value)\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: task-count\n  namespace: keda\ndata:\n  count: \"42\"\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: task-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: worker-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"task-count\"\n        key: \"count\"\n        format: \"number\"\n        valueType: \"float64\"\n        targetValue: \"50\"\n        activationTargetValue: \"10\"\n```\n\nIn this example, the value `42` from the `count` key is used directly.\n\n#### Example 2: JSON Format\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: metrics-data\n  namespace: keda\nstringData:\n  metrics: |\n    {\n      \"queue\": {\n        \"pending\": 25,\n        \"processing\": 5\n      }\n    }\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: queue-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: processor-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"Secret\"\n        resourceName: \"metrics-data\"\n        key: \"metrics\"\n        format: \"json\"\n        valueLocation: \"queue.pending\"\n        valueType: \"int64\"\n        targetValue: \"20\"\n```\n\nIn this example, the GJSON path `queue.pending` extracts the value `25` from the JSON data.\n\n#### Example 3: YAML Format with Nested Path\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: app-metrics\n  namespace: keda\ndata:\n  stats: |\n    application:\n      workers:\n        active: 15\n        idle: 3\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: worker-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: worker-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"app-metrics\"\n        key: \"stats\"\n        format: \"yaml\"\n        valueLocation: \"application.workers.active\"\n        valueType: \"int64\"\n        targetValue: \"10\"\n```\n\nIn this example, the dot-separated path `application.workers.active` extracts the value `15` from the YAML data.\n\n#### Example 4: Quantity Type\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: resource-limits\n  namespace: keda\ndata:\n  memory: |\n    {\n      \"available\": \"2Gi\",\n      \"used\": \"512Mi\"\n    }\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaler\n  namespace: keda\nspec:\n  scaleTargetRef:\n    name: worker-deployment\n  triggers:\n    - type: kubernetes-resource\n      metadata:\n        resourceKind: \"ConfigMap\"\n        resourceName: \"resource-limits\"\n        key: \"memory\"\n        format: \"json\"\n        valueLocation: \"used\"\n        valueType: \"quantity\"\n        targetValue: \"1024000000\"  # 1Gi in bytes\n```\n\nIn this example, the quantity string `\"512Mi\"` is parsed and converted to its float64 representation for scaling decisions.\n\n> ⚠️ **Important:** When using `valueType: \"int64\"` with JSON format, decimal values will be truncated. For example, if the JSON contains `{\"count\": 25.7}`, it will be treated as `25`.\n\n### Supported Formats and Value Extraction\n\nThe scaler works in two steps:\n\n1. **Retrieve the raw string**: Read the value from `ConfigMap.data[key]` or `Secret.data[key]`\n2. **Extract the metric**: Parse the raw string based on the `format`:\n   - **number**: The raw string is parsed directly as a number. No `valueLocation` is needed.\n     - Example: If `key=\"count\"` and `ConfigMap.data.count = \"42\"`, the metric value is `42`\n   - **json**: The raw string is parsed as JSON, then `valueLocation` (using GJSON syntax) extracts the metric value.\n     - Example: If `key=\"metrics\"` and `ConfigMap.data.metrics = '{\"tasks\": 10}'`, with `valueLocation=\"tasks\"`, the metric value is `10`\n   - **yaml**: The raw string is parsed as YAML, then `valueLocation` (using dot-separated path) extracts the metric value.\n     - Example: If `key=\"stats\"` and `ConfigMap.data.stats = 'count: 15'`, with `valueLocation=\"count\"`, the metric value is `15`\n\n### Limitations\n\n- Only resources in the same namespace as the ScaledObject are supported.\n- No cross-namespace access.\n- Only ConfigMaps and Secrets are supported.\n- The scaler uses the KEDA operator's service account permissions to access resources.\n\n### See Also\n\n- [KEDA Concepts: Activating and Scaling Thresholds](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds)\n- [GJSON Path Syntax](https://github.com/tidwall/gjson#path-syntax)\n"
  },
  {
    "path": "content/docs/2.20/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on the count of matching non-terminated pods, optionally grouped by node.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    groupByNode: 'true'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) used to match pods for this scaler. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the count computed by this scaler. By default, the count is the number of matching non-terminated pods. If `groupByNode` is set to `true`, the count is the number of unique nodes hosting matching non-terminated pods. Matching pods without a node assignment are excluded. It will be calculated following this formula: `relation = (scaler-computed count) / (scaled workload pods)`. (This value can be a float)\n- `groupByNode` - When set to `true`, matching non-terminated pods are grouped by `spec.nodeName`, so multiple matching pods on the same node count as `1`. Matching pods without an assigned node are excluded. (Default: `false`, Optional)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\nWhen `groupByNode` is enabled, KEDA groups matching non-terminated pods by node and excludes matching pods without a node assignment. For example, if `7` matching pods are found and `2` of them run on the same node, the scaler reports `6`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n      groupByNode: 'true'\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Apps\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler can scale to 0 only when user defines at least one additional scaler which is not CPU or Memory (eg. Kafka + Memory, or Prometheus + Memory) and `minReplicaCount` is 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include at least one of `requests` or `limits`.\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests` (or `limits`). See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar), KEDA checks if the `defaultRequest` (or `default` for limits) is set in `LimitRange` for the `Container` type in the same namespace. If `defaultRequest` (or `default` for limits) is missing too, the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n  - type: metrics-api\n    metadata:\n      targetValue: \"8.8\"\n      format: \"json\"\n      activationTargetValue: \"3.8\"\n      url: \"http://api:3232/api/v1/stats\"\n      valueLocation: \"components.worker.tasks\"\n      timeout: \"1000\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n  If `aggregateFromKubeServiceEndpoints` is set to `true`, the URL must use Kubernetes DNS format:\n  `http://<service>.<namespace>[.svc.cluster.local]:<pod-port>/path`, where the port must be the pod port\n  targeted by the service, not the service port.\n- `format` - One of the following formats: `json`, `xml`, `yaml`, `prometheus`. (Default: `json`, Optional)\n- `valueLocation` - The location of the metric value in the response payload. The value is format specific.\n  * `json` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n  * `yaml`, `xml`, `prometheus` - implemented as dot-separated path algorithm for value parsing.\n    * `{foo: {bar: 42}}` - `foo.bar` will return 42\n    * `{foo: [{bar: 42}]}` - `foo.0.bar` will return 42\n    * same syntax is used for `yaml`, `xml` and `prometheus` formats.\n\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - Timeout for this specific trigger. Can be given as a number (in milliseconds) or in a human-readable format like \"30s\". This value will override the value defined in KEDA_HTTP_DEFAULT_TIMEOUT. (Optional)\n- `aggregateFromKubeServiceEndpoints` - Whether to treat `url` as a kubernetes service and scrape/aggregate metrics for all of this service's endpoints. (Values: `true`, `false`, Default: `false`, Optional)\n- `aggregationType` - How to aggregate metrics when `aggregateFromKubeServiceEndpoints` is set to `true`, ignored otherwise. (Values: `average`, `sum`, `max`, `min`, Default: `average`, Optional)\n\n### Note on aggregation from kubernetes service\n\nwhen setting `aggregateFromKubeServiceEndpoints: true` in metadata, Metrics API Scaler is able to compute basic `average`, `sum`, `min` or `max` aggregation asked by `aggregationType` metadata from all endpoint targets of a kubernetes API service, which is a handy feature in an environment where one didn't set up a metric aggregator/scraping stack (i.e prometheus), or simply doesn't want to use their monitoring stack to fetch and serve metrics from customers workload in their own kubernetes clusters, and leave the metrics API's responsibility up to the customer\n\nThis specific behavior comes from the fact that querying a kubernetes service directly (= setting `aggregateFromKubeServiceEndpoints: false`) would return the metric from a single replica randomly, depending on the load-balancing configuration for the service, and lead to inconsistent HPA average metric computation and eventually to scaling issues as metrics from all replicas won't be taken into account\n\nHere is an example of a ScaledObject using `aggregateFromKubeServiceEndpoints`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"8.8\"\n        url: \"http://my-service.my-namespace.svc.cluster.local:8080/api/v1/stats\"\n        valueLocation: \"components.worker.tasks\"\n        aggregateFromKubeServiceEndpoints: \"true\"\n        aggregationType: \"sum\"\n```\n\n### Authentication Parameters\n\nMetrics Scaler API supported four types of authentication - API Key based authentication, basic authentication, TLS\nauthentication, and Bearer authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below. Multiple authentication methods can be used simultaneously by providing a comma-separated list in the `authMode` parameter, for example `authMode: \"apiKey,tls\"` enables both API key and TLS certificate authentication in a single request.\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # scheme of the MongoDB server. if using MongoDB Altas, you can set it to \"mongodb+srv\"\n      scheme: \"mongodb\"\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur. This value can be a float.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional). This value can be a float.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb[+srv]://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `scheme` - The scheme of the MongoDB server, if using MongoDB Atlas, you can set it to `mongodb+srv`. (Default: `mongodb`, Optional)\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n**Azure AD Workload Identity authentication:**\n\n> Available in v2.20+\n\n#### Prerequisites:\n- The Azure SQL server has an Azure AD admin configured. See [Microsoft Learn: Configure and manage Microsoft Entra authentication with Azure SQL](https://learn.microsoft.com/azure/azure-sql/database/authentication-aad-configure).\n- The user-assigned managed identity (UAMI) is federated to the Kubernetes service account used to authenticate against Azure SQL. See the [Considerations about Federations and Overrides](./../authentication-providers/azure-ad-workload-identity.md#considerations-about-federations-and-overrides) section, and the [azure-workload-identity federated credential docs](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) for the underlying setup.\n- A contained database user mapped to the UAMI exists in the target database, e.g. `CREATE USER [<UAMI_NAME>] FROM EXTERNAL PROVIDER;`, and has been granted access to the objects referenced in the scaler's query. See [Microsoft Learn: Azure AD authentication overview](https://learn.microsoft.com/azure/azure-sql/database/authentication-aad-overview).\n\nWhen `azure-workload` pod identity is used, KEDA acquires an Azure AD access token and uses it as the credential for each query — no `password` / `passwordFromEnv` is required. The scaler accepts the same individual connection parameters as **Password authentication**, with `username` set to the UAMI's contained-database user name:\n\n- `host` - FQDN of the Azure SQL server (e.g. `<server-name>.database.windows.net`).\n- `port` - The port number of the MSSQL endpoint. (Default: `1433`, Optional)\n- `database` - The name of the database to query.\n- `username` - Name of the UAMI's contained database user.\n\n#### Remarks\n\nKEDA refreshes the Azure AD access token automatically before its expiry. Tokens are scoped to the Azure SQL resource (`https://database.windows.net/.default`).\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-mssql-wi-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n    - type: mssql\n      authenticationRef:\n        name: azure-mssql-wi-auth\n      metadata:\n        host: <AZURE_SQL_SERVER_FQDN>\n        port: \"1433\"\n        database: <DB_NAME>\n        username: <UAMI_NAME>\n        query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n        targetValue: 1\n```\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n- `usernameFromEnv` - The username for connecting with host of the MySQL server, similar to `username`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nSome parameters of the JetStream details can be pulled from `TriggerAuthentication` objects:\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n> **Notice:**\n> The Stan scaler (NATS Streaming) is DEPRECATED and will be removed in v2.19 - Use scaler [nats-jetstream](./nats-jetstream.md) instead.\n> See also the deprecation notice [here](https://nats-io.gitbook.io/legacy-nats-docs/nats-streaming-server-aka-stan).\n\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n**TLS Authentication**\n\n- `tls` - To enable SSL auth for nats-streaming, set this to `enable`. If not set, TLS for nats-streaming is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### Example without any TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with no TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n\n#### Example with TLS\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-stan-secrets\n  namespace: default\ndata:\n  tls: enable\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-stan-secrets\n      key: tls\n    - parameter: ca\n      name: keda-stan-secrets\n      key: ca\n    - parameter: cert\n      name: keda-stan-secrets\n      key: cert\n    - parameter: key\n      name: keda-stan-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"true\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\nAutoscaling trigger based on transaction duration average metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n\nAutoscaling trigger based on transaction count [rate](https://docs.newrelic.com/docs/nrql/using-nrql/rate-function/) metric:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT rate(count(*), 10 SECOND) FROM Transaction WHERE appName='SITE' SINCE 1 MINUTE AGO\"\n        noDataError: \"true\"\n        threshold: '300'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/nsq.md",
    "content": "+++\ntitle = \"NSQ\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on NSQ topic/channel depth.\"\ngo_file = \"nsq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nsq` trigger that scales based on [NSQ](https://github.com/nsqio/nsq) topic/channel depth. \n\n```yaml\ntriggers:\n- type: nsq\n  metadata:\n    nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n    topic: \"example_topic\"\n    channel: \"example_channel\"\n    depthThreshold: \"10\"\n    activationDepthThreshold: \"0\"\n    useHttps: \"false\"\n    unsafeSsl: \"false\"\n```\n\n**Parameter list:**\n\n- `nsqLookupdHTTPAddresses` - Comma separated list of [nsqlookupd](https://nsq.io/components/nsqlookupd.html) HTTP addresses in the form `<hostname>:<port>`.\n- `topic` - Name of the NSQ datastream that the `channel` relates to.\n- `channel` - Name of the channel used to calculate depth.\n- `depthThreshold` - Target value for depth to trigger scaling actions. (Default `10`, Optional)\n- `activationDepthThreshold` - Target value for depth to activate the scaler. (Default `0`, Optional)\n- `useHttps` - Use HTTPS instead of HTTP when communicating with NSQ. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n> **Notice:**\n> - Since [\"channels are created on first use by subscribing to the named channel\"](https://nsq.io/overview/design.html#simplifying-configuration-and-administration), the topic depth is used instead of the channel depth when the channel does not yet exist on an [nsqd](https://nsq.io/components/nsqd.html) instance. This allows KEDA to effectively bootstrap new channels when the `minReplicaCount` is 0.\n> - If the message flow for a channel is paused, KEDA will not scale up consumers of the channel, regardless of the depth.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nsq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nsq-consumer-deployment\n  triggers:\n  - type: nsq\n    metadata:\n      nsqLookupdHTTPAddresses: \"nsq-nsqlookupd.nsq:4161\"\n      topic: \"example_topic\"\n      channel: \"example_channel\"\n      depthThreshold: \"10\"\n      activationDepthThreshold: \"0\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.20/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for three connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret).\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nIt is also possible to leverage a `TriggerAuthentication` object having the `azure-workload`'s provider type to connect to an Azure Postgres Flexible Server resource through an UAMI Azure managed identity.  \nMore details and an example are provided down below.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return a numeric value (integers and floats are both supported).\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n\n> Note that the query must return a single numeric value (integers and floats are both supported). If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password, or store the password within the connectionString, or leverage Azure Access Token authentication to connect to a Azure Postgres Flexible Server.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n\n**Azure Access Token authentication:**\n\n#### Prerequisites:\n- The UAMI should be able to access the Azure Postgres Flexible Server, [refer to this link for more info](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity#create-an-azure-database-for-postgresql-flexible-server-user-for-your-managed-identity).\n- The UAMI should be granted access to the table mentioned in the query performed by KEDA.  \nThis can be achieved by:\n  - creating a group role to allow access to the particular schema where the table queried by KEDA is persisted, and then assign the newly created Postgres user identity from previous step to this group role.\n  - granting permission on the table queried by KEDA to the newly created Postgres user from previous step, via a query that looks like  \n  `GRANT ALL ON <TABLE_REF> TO \"<AZURE_UAMI_NAME>\";`.\n\nNext, a user can specify individual arguments (host, userName, password, etc.), and the scaler will form a connection string internally. An access token, which will act as a password, will be retrieved each time KEDA performs its process.\n  - `host` - FQDN of the Azure Postgres Flexible Server.\n  - `userName` - Name of the UAMI Azure identity (`<AZURE_UAMI_NAME>`).\n  - `port` - Postgresql port (the default value is `\"5432\"`, please have a look at the `Remarks` down below).\n  - `dbName` - Postgresql Database name.\n  - `sslmode` - SSL policy for communicating with database (the value should be `require`).\n\n\n#### Remarks\n\n- While the Azure Postgres Flexible Server resource provides a [`PGBouncer`](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-pgbouncer) feature which opens a port `6432` to interact with the server, this access token authentication's feature was not working properly while using the `PGBouncer` port, but it worked without issues while using the default server's port. Therefore, KEDA should use the Postgres server's default port, but the other applications (i.e. Airflow, ...) deployed on the same Kubernetes cluster can use the `PGBouncer` port.\n\n\n#### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-pg-flex-auth\nspec:\n  podIdentity:\n    provider: azure-workload\n    # Optional-> identityId: <UAMI_IDENTITY_ID>\n    # Optional-> identityTenantId: <UAMI_TENANT_ID>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      authenticationRef:\n        name: azure-pg-flex-auth\n      metadata:\n        host: <AZURE_POSTGRES_FLEX_SERVER_FQDN>\n        port: \"5432\"\n        userName: <UAMI_NAME>\n        dbName: <DB_NAME>\n        sslmode: require\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```"
  },
  {
    "path": "content/docs/2.20/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ncategory = \"Metrics\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    customHeaders: X-Client-Id=cid,X-Tenant-Id=tid,X-Organization-Id=oid # Optional. Custom headers to include in query. In case of auth header, use the custom authentication or relevant authModes.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    queryParameters: key-1=value-1,key-2=value-2\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint    \n    timeout: \"1000\" # Optional. Custom timeout for the HTTP client used in this scaler\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `customHeaders` - Custom headers to include while querying the prometheus endpoint. In case of authentication headers, use custom authentication or relevant `authModes` instead. (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `queryParameters` - A comma-separated list of query Parameters to include while querying the Prometheus endpoint. (Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n- `timeout` - Timeout **for this specific trigger**. Can be given as a number (in milliseconds) or in a human-readable format like \"30s\". This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports various types of authentication to help you integrate with Prometheus.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n**Custom authentication:**\n- `authModes`: It must contain `custom` in case of Custom Authentication. Specify this in trigger configuration.\n- `customAuthHeader`: Custom Authorization Header name to be used. This is required field.\n- `customAuthValue`: Custom Authorization Header value. This is required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Integrating Cloud offerings\n\n#### Amazon Managed Service for Prometheus\n\nAmazon Web Services (AWS) offers a [managed service for Prometheus](https://aws.amazon.com/prometheus/) that provides a scalable and secure Prometheus deployment. The Prometheus scaler can be used to run Prometheus queries against this managed service.\n\n- [EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) provider can be used in `authenticationRef` - see later in example. TriggerAuthentication and Secret are also supported authentication methods.\n- Create Amazon Managed Service for Prometheus [workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) in your AWS account\n- Retrieve the Prometheus query endpoint URL from the [AWS managed Prometheus Workspace](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html). This endpoint will be used to send queries.\n- Configure Prometheus scaler to use the workspace endpoint and an authentication method like EKS Pod Identity.\n\nUsing the managed service eliminates the operational burden of running your own Prometheus servers. Queries can be executed against a fully managed, auto-scaling Prometheus deployment on AWS. Costs scale linearly with usage.\n\nTo gain a better understanding of creating a Prometheus trigger for Amazon Managed Service for Prometheus, refer to [this example](#example-amazon-managed-service-for-prometheus-amp).\n\n#### Azure Monitor Managed Service for Prometheus\n\nAzure has a [managed service for Prometheus](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) and Prometheus scaler can be used to run prometheus query against that.\n- [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) provider can be used in `authenticationRef` - see later in example.\n- `Monitoring Data Reader` role needs to be assigned to workload identity (or pod identity) on the `Azure Monitor Workspace`.\n- No other auth (via `authModes`) can be provided with Azure Pod/Workload Identity Auth.\n- Prometheus query endpoint can be retrieved from [Azure Monitor Workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/azure-monitor-workspace-overview) that was configured to ingest prometheus metrics.\n\nTo gain a better understanding of creating a Prometheus trigger for Azure Monitor Managed Service for Prometheus, refer to [this example](#example-azure-monitor-managed-service-for-prometheus).\n\n#### Google Managed Service for Prometheus\n\nGoogle Cloud Platform provides a comprehensive [managed service for Prometheus](https://cloud.google.com/stackdriver/docs/managed-prometheus), enabling you to effortlessly export and query Prometheus metrics.\nBy utilizing Prometheus scaler, you can seamlessly integrate it with the GCP managed service and handle authentication using the GCP workload identity mechanism.\n\nSee the following steps to configure the scaler integration.\n\n- Setup [GCP Workload Identity](./../authentication-providers/gcp-workload-identity) on KEDA operator;\n- Assign the [Monitoring Viewer](https://cloud.google.com/iam/docs/understanding-roles#monitoring.viewer) role (namely `roles/monitoring.viewer`) to the Google Service Account on Identity Access and Management (IAM).\n- No other auth (via `authModes`) should be provided other than GCP workload identity auth;\n- Prometheus server address should follow the Google's Monitoring API for [Prometheus HTTP API](https://cloud.google.com/stackdriver/docs/managed-prometheus/query#api-prometheus):\n  - Example: `https://monitoring.googleapis.com/v1/projects/GOOGLE_PROJECT_ID/location/global/prometheus` - where `GOOGLE_PROJECT_ID` should be replaced by your Google project ID.\n\nTo gain a better understanding of creating a Prometheus trigger for Google Managed Prometheus, refer to [this example](#example-google-managed-prometheus).\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\n#### Example: Bearer Authentication\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Basic Authentication\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS Authentication\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: TLS & Basic Authentication\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Custom Authentication\n\nHere is an example of a prometheus scaler with Custom Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  customAuthHeader: \"X-AUTH-TOKEN\"\n  customAuthValue: \"auth-token\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: customAuthHeader\n      name: keda-prom-secret\n      key: customAuthHeader\n    - parameter: customAuthValue\n      name: keda-prom-secret\n      key: customAuthValue\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"custom\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n#### Example: Azure Monitor Managed Service for Prometheus\n\nHere is an example of a prometheus scaler with Azure Pod Identity and Azure Workload Identity, define the `TriggerAuthentication` and `ScaledObject` as follows\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-managed-prometheus-trigger-auth\nspec:\n  podIdentity:\n      provider: azure-workload\n      identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://test-azure-monitor-workspace-name-9ksc.eastus.prometheus.monitor.azure.com\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      threshold: '100.50'\n      activationThreshold: '5.5'\n    authenticationRef:\n      name: azure-managed-prometheus-trigger-auth\n```\n#### Example: Amazon Managed Service for Prometheus (AMP)\n\nBelow is an example showcasing the use of Prometheus scaler with AWS EKS Pod Identity. Please note that in this particular example, the Deployment is named as `keda-deploy`. Also replace the AwsRegion and AMP WorkspaceId for your requirements.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\nspec:\n  podIdentity:\n    provider: aws\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-deploy\n  labels:\n    app: keda-deploy\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: keda-deploy\n  template:\n    metadata:\n      labels:\n        app: keda-deploy\n    spec:\n      containers:\n      - name: nginx\n        image: nginxinc/nginx-unprivileged\n        ports:\n        - containerPort: 80\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda-so\n  labels:\n    app: keda-deploy\nspec:\n  scaleTargetRef:\n    name: keda-deploy\n  maxReplicaCount: 2\n  minReplicaCount: 0\n  cooldownPeriod: 1\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 15\n  triggers:\n    - type: prometheus\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        awsRegion: {{.AwsRegion}}\n        serverAddress: \"https://aps-workspaces.{{.AwsRegion}}.amazonaws.com/workspaces/{{.WorkspaceID}}\"\n        query: \"vector(100)\"\n        threshold: \"50.0\"\n        identityOwner: operator\n```\n\n#### Example: Google Managed Prometheus\n\nBelow is an example showcasing the use of Prometheus scaler with GCP Workload Identity. Please note that in this particular example, the Google project ID has been set as `my-google-project`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: google-workload-identity-auth\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: google-managed-prometheus-scaler\nspec:\n  scaleTargetRef:\n    name: deployment-name-to-be-scaled\n  minReplicaCount: 1\n  maxReplicaCount: 20\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: https://monitoring.googleapis.com/v1/projects/my-google-project/location/global/prometheus\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n      threshold: '50.0'\n    authenticationRef:\n      kind: ClusterTriggerAuthentication\n      name: google-workload-identity-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`, `basic`, `oauth`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `scope` - A comma separated lists of OAuth scopes, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `clientID` - Client ID for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n- `endpointParams` - Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider, used when `authModes` is set to `oauth`. Ignored if provided from `authenticationRef`. (Optional)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n**OAuth 2**\n\nWhen configuring OAuth Authentication, configure the following:\n- `oauthTokenURI` - The OAuth Access Token URI for the OAuth provider. (Optional)\n- `scope` -  A comma separated lists of OAuth scopes. (Optional)\n- `clientID`: Client ID for the OAuth provider. (Optional)\n- `clientSecret`: Client secret for the OAuth provider. (Optional)\n- `endpointParams`: Additional parameters as URL-encoded query string for requests to the token endpoint for the OAuth provider. (Optional)\n\nThese can also be configured in the trigger metadata except the `clientSecret`\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### OAuth Authentication\n\nIn order to enable Pulsar's OAuth Authentication feature, you can use the following example. Note that only client credentials flow is supported.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  oauthTokenURI: <your OAuth URI>\n  scope: <your Scope>\n  clientID: <your clientID>\n  clientSecret: <your clientSecret>\n  endpointParams: <your endpointParams>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: oauthTokenURI\n    name: keda-pulsar-secrets\n    key: oauthTokenURI\n  - parameter: scope\n    name: keda-pulsar-secrets\n    key: scope\n  - parameter: clientID\n    name: keda-pulsar-secrets\n    key: clientID\n  - parameter: clientSecret\n    name: keda-pulsar-secrets\n    key: clientSecret\n  - parameter: endpointParams\n    name: keda-pulsar-secrets\n    key: endpointParams\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\nYou can also use the following example without `authenticationRef` if your OAuth provider supports.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"oauth\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n      oauthTokenURI: http://oauth.com/oauth2/token\n      scope: <your scope>\n      clientID: <your clientID>\n      endpointParams: <your endpointParams>\n```"
  },
  {
    "path": "content/docs/2.20/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://<host>:<port>/<vhost> # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either `amqp`, `http`, or `auto` for auto-detection based on the `host` value. Default value is `auto`.\n    mode: QueueLength # Supported modes are `QueueLength`, `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` or `ExpectedQueueConsumptionTime`\n    value: \"100.50\" # A value defining the threshold (per instance) that, when exceeded, triggers the scaling.\n    activationValue: \"10.5\" # Optional. Activation threshold, which by default is 0.\n    queueName: testqueue # Name of the queue.\n    vhostName: / # Optional. If not specified, use the VHost in the `host` connection string. Required for Azure AD Workload Identity authorization (see below).\n    # You can use existing environment variables to read configuration from. For details see \"Parameters list\" section.\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter.\n    usernameFromEnv: RABBITMQ_USERNAME # Optional. You can use this instead of `TriggerAuthentication`.\n    passwordFromEnv: RABBITMQ_PASSWORD # Optional. You can use this instead of `TriggerAuthentication`.\n    unsafeSsl: true # Optional. Whether to allow unsafe SSL connections.\n    timeout: 1000 # Optional. Custom timeout for the HTTP client used in this scaler.\n```\n\n**Parameters list:**\n\n- `host` - RabbitMQ host address in the format `<protocol>://<host>:<port>/vhost`. If the protocol is HTTP than the host may follow this format `http://<host>:<port>/<path>/<vhost>`. In example, the resolved host value could be `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/path/vhost`. If the host doesn't contain `vhost`, then the trailing slash is required, e.g. `http://guest:password@localhost:5672/`. When using a username with password consider using `hostFromEnv` or a `TriggerAuthentication`.\n- `queueName` - Name of the queue to read required information and stats from.\n- `mode` - Trigger mode. See [Choosing the right trigger mode](#choosing-the-right-trigger-mode) for additional details. Can be one of:\n  - `QueueLength` - trigger on number of messages in the queue\n  - `MessageRate` - trigger on the publishing rate reported by the queue\n  - `DeliverGetRate` - trigger on the rate of delivered messages (to consumers or in response to `basic.get`, both acknowledged and not) reported by the queue\n  - `PublishedToDeliveredRatio` - trigger on the value of ratio of `MessageRate` to `DeliverGetRate`\n  - `ExpectedQueueConsumptionTime` - trigger on the value of expected time (in seconds) of consumption of all messages currently available in the queue (utilizes `QueueLength`, `MessageRate` and `DeliverGetRate` metrics).\n- `value` - A value defining the threshold (per instance) that, when exceeded, triggers the scaling (can be a floating-point number depending on the trigger mode).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds) (default: `0`; optional; can be a floating-point number).\n- `protocol` - Protocol to be used for communication (values: `auto`, `http`, `amqp`; default: `auto`; optional).\n- `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (it's optional by default but **it is required** if Azure AD Workload Identity authorization is used).\n- `queueLength` - **DEPRECATED: please use `mode: QueueLength` and `value: ##` instead**. Defines a threshold value for the queue length passed to the scaler. For example: if one pod can handle 10 messages, set the queue length target to `10`. If the actual number of messages in the queue is 30, the scaler will scale up to 3 pods. Default is set to `20` unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of using full name (values: `true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol).\n- `pageSize` - This parameter allows setting the page size (default: `100`; optional; only applies when `useRegex` is set to `true`).\n- `operation` - Operation that will be applied to compute the number of messages in case when `useRegex` is enabled (values: `sum`, `max`, `avg`; defaults: `sum`; optional).\n- `timeout` - Timeout in milliseconds **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT` (optional; only applies to hosts that use the `http` protocol).\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (ready messages only; values:`true`, `false`; default: `false`; optional; only applies to hosts that use the `http` protocol).\n- `unsafeSsl` - Whether to allow unsafe SSL connections (values: `true`, `false`, default: `false`).\n\nSome parameters can be provided using environment variables instead of setting them directly in metadata:\n- `hostFromEnv` - reads the host and port of the RabbitMQ server from selected environment variable (in similar format as `host` parameter)\n- `usernameFromEnv` - reads the username from selected environment variable, which is used to connect to the broker’s management endpoint\n- `passwordFromEnv` - reads the password from selected environment variable, which is used to connect to the broker’s management endpoint.\n\n> 💡 **Notes:** \n> - `host`/`hostFromEnv` has an optional VHost name after the host slash which will be used to scope API request\n> - when using `host`/`hostFromEnv` or `TriggerAuthentication`, the supplied password cannot contain special characters\n> - trigger modes `MessageRate`, `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` require `http` protocol.\n> - setting `useRegex` to `true` also requires `protocol` to be set to `http`.\n\n> ⚠ **Important:**\n> - If you have unacknowledged messages and you want to have these counted for the scaling to happen, make sure to utilize the `http` protocol (only REST API interface allows for these to be counted).\n> - If scaling against many is desired, then the `ScaledObject` should have all desired triggers defined. HPA will scale based on the largest result considering each of triggers independently.\n\n### Choosing the right trigger mode\n\nBelow you can find available trigger modes with most common usage scenarios:\n- `QueueLength` - Mainly used to scale messages consuming services, where it is desired to keep number of messages in the queue at selected, nominal level.\n- `MessageRate` - Mainly used to scale messages consuming services, where it is desired to keep the consumption rate up to messages publication rate (or higher).\n- `DeliverGetRate` - This specific trigger is actually a byproduct of the resulting implementation of `PublishedToDeliveredRatio` trigger (it was implemented to be used within `scalingModifiers` as a part of composite metric), yet it still has its use in some scenarios. E.g. assuming there's a well known consumer service performance ballpark, `DeliverGetRate` trigger can be utilized to scale out messages publishing service in order to increase publication rate. In this particular example however, upper publication rate limit must be properly guarded by another trigger or by [`maxReplicaCount`](./../reference/scaledobject-spec/#maxreplicacount) so as not to scale infinitely (which could result in overloading the broker, or consumers, or both).\n- `PublishedToDeliveredRatio` - This trigger is used mainly to control consumer pods scaling to keep publishing and consuming rates at stable level. Assuming that this is the case, the principle of operation is this:\n  - if publishing rate is greater than `value` (usually it is a value slightly above `1`), trigger will initiate scale-out process to launch more consumer pods\n  - if publishing rate is equal to consumption rate (value `1`) then it is the indicator that capacity of consumers is sufficient for handling ongoing messages processing and no additional pods need to be added to the pool\n  - if ratio is below `1`, HPA can gracefully take down some consumers but keep messages processing rate at stable level.\n- `ExpectedQueueConsumptionTime` - A trigger primarily used to scale consumer pods, which uses estimate value of pending time to deliver all available messages in the queue to the consumers. If it becomes active in this particular scenario, returned metric indicates growing number of messages due either increased publishing rate or degraded performance of currently active number of consumers. It relies on proper setting of `pollingInterval` (see below for details).\n\n> ⚠ **Important:**\n> - With `DeliverGetRate`, `PublishedToDeliveredRatio` and `ExpectedQueueConsumptionTime` it is advised to set `metricType: Value` in the trigger configuration to rely on absolute metric value and not the average value across all scaled pods. For reference see [`triggers.metricType`](./../reference/scaledobject-spec/#triggers) and [`scalingModifiers.metricType`](./../reference/scaledobject-spec/#scalingmodifiersmetrictype).\n> - When using `PublishedToDeliveredRatio`, having stable publication to consumption rate may not indicate that consumers pool is of the right size to do the job, since the messages consuming capabilities can change over time, which may result in much higher number of consumers than actually needed. It is then recommended to periodically re-evaluate consumers pool size using different, probably external metric (e.g. consumers count number, size of prefetch buffer, consumer performance, etc.).\n> - Since `ExpectedQueueConsumptionTime` trigger mode is based on the expected time (in seconds) for the selected queue to be emptied of all messages (including estimated count of published messages during sample probing), it must be served with `pollingInterval` set to 1 second. However, in case where such frequent polling may be expensive, it is recommended to use `ExpectedQueueConsumptionTime` in `scalingModifiers` using additional triggers values in formula like so: `(ExpectedQueueConsumptionTime - (QueueLength / DeliverGetRate)) * pollingInterval + (QueueLength / DeliverGetRate)`.\n\n### Authentication Parameters\n\n`TriggerAuthentication` CRD is used to connect and authenticate to RabbitMQ:\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/path/vhost`.\n  > See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n- `vhostName` - VHost to use for the connection, overrides any VHost set in the connection string from `host`/`hostFromEnv` (optional, but **required** if Azure AD Workload Identity authorization is used).\n\n#### Username and Password based authentication\n\nThis allows sensitive credentials to be stored and managed separately from the connection string:\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n> 💡 **Note:** If username or password are set in `TriggerAuthentication` or environment variables, they will override any credentials provided in the `host` parameter.\n\n#### TLS authentication\n\n- `tls` - To enable SSL auth for RabbitMQ, set this to `enable`. If not set, TLS for RabbitMQ will not be used. Valid values are `enable` or `disable` (optional; the default is `disable`).\n- `ca` - Certificate authority file for TLS client authentication (optional).\n- `cert` - Certificate for client authentication (optional).\n- `key` - Certificate Key for client authentication (optional).\n\n> 💡 **Note:** Using RabbitMQ host with AMQPS protocol will require enabling the TLS settings and passing the required parameters.\n\n#### Azure Workload Identity authentication\n\nFor RabbitMQ with OIDC support (>= 3.11) you can use `TriggerAuthentication` CRD with `podIdentity.provider = azure-workload` and with `workloadIdentityResource` parameter, which will hold application identifier of App Registration in Azure AD. In this case `username:password` part in host URI should be omitted and `vHostName` has to be set explicitly in `ScaledObject`. Currently, only HTTP protocol is supported for AKS Workload Identity.\n\n### Configuration examples\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672\n  vhostName: vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: vhostName\n      name: keda-rabbitmq-secret\n      key: vhostName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQP protocol with username and password authorization:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://localhost:5672/vhost (no username/password)\n  username: <username> # base64 encoded value of username\n  password: <password> # base64 encoded value of password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: username\n      name: keda-rabbitmq-secret\n      key: username\n    - parameter: password\n      name: keda-rabbitmq-secret\n      key: password \n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### AMQPS protocol with TLS authorization:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQPS URI connection string> # base64 encoded value of format amqps://guest:password@localhost:5672/vhost\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: tls\n      name: keda-rabbitmq-secret\n      key: tls\n    - parameter: ca\n      name: keda-rabbitmq-secret\n      key: ca\n    - parameter: cert\n      name: keda-rabbitmq-secret\n      key: cert\n    - parameter: key\n      name: keda-rabbitmq-secret\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `MessageRate` and `QueueLength` triggers):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger) and enabled `useRegex`:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `QueueLength` trigger) with Azure Workload Identity:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://localhost:15672/ !! no password !!\n  clientId: <RabbitMQ AzureAD App Registration Client ID> # base64 encoded value of Client ID (same as for Rabbit's auth_oauth2.resource_server_id)\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  podIdentity:\n    provider: azure-workload\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n    - parameter: workloadIdentityResource\n      name: keda-rabbitmq-secret\n      key: clientId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      vHostName: /\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (with `DeliverGetRate` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: DeliverGetRate\n      value: \"30\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n\n#### HTTP protocol (with `PublishedToDeliveredRatio` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: PublishedToDeliveredRatio\n      value: \"1.1\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n\n#### HTTP protocol (with `PublishedToDeliveredRatio` trigger used together with `scalingModifiers`)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    name: p2d_ratio\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: PublishedToDeliveredRatio\n      value: \"1\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n  - type: rabbitmq\n    name: qlen\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"100\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n  advanced:\n    # Bind QueueLength and PublishedToDeliveredRatio together to control trigger value\n    scalingModifiers:\n      metricType: Value\n      # Trigger if either one of conditions is met:\n      # - publishing to delivery rate exceeds factor of 1.2\n      # - queue length contains more than 1.2K messages\n      formula: \"max(p2d_ratio, qlen/1000)\"\n      target: 1.2\n```\n\n#### HTTP protocol (with `ExpectedQueueConsumptionTime` trigger)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/path/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  pollingInterval: 1\n  triggers:\n  - type: rabbitmq\n    metricType: Value\n    name: eqct\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: ExpectedQueueConsumptionTime\n      value: \"20\"\n    authenticationRef:\n      name: rabbitmq-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for; similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"myprimary\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the primary (still referred to as the 'master' in Sentinel) in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"myprimary\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n        sentinelMaster: \"myprimary\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThere are three ways to configure `redis-streams` trigger:\n1. Based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream\n2. Based on the *Stream Length* (see [`XLEN`](https://redis.io/commands/xlen))\n3. Based on the *Consumer Group Lag* (see [`XINFO GROUPS`](https://redis.io/commands/xinfo-groups/)). This is the only configuration that supports scaling down to 0. IMPORTANT: Redis 7+ is required for this feature to run.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # optional - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # optional - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    streamLength: \"50\" # optional - Redis stream length, alternative to pendingEntriesCount scaler trigger\n    lagCount: \"5\" # optional - number of lagging entries in the consumer group, alternative to pendingEntriesCount scaler trigger\n    activationLagCount: \"3\" # required if lagCount is provided - lag count at which scaler triggers\n    enableTLS: \"false\" # optional\n    unsafeSsl: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n> Setting the `consumerGroup` causes the scaler to operate on `pendingEntriesCount`. Lack of `consumerGroup` will cause the scaler to be based on `streamLength`\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `streamLength` - Threshold for stream length, alternative average target value to scale workload. (Default: `5`, Optional)\n- `lagCount` - Threshold for the consumer group lag number, alternative average target value to scale workload. (Default: `5`, Optional)\n- `activationLagCount` - Lag count threshold at which to start scaling. Any average lag count below this value will not trigger the scaler. (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional, This requires `enableTLS: true`)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\n**TLS:**\n\nParameters used for configuring TLS authentication. Note this can not be used together with `enableTLS` and `unsafeSsl` on the `ScaledObject`, which is used to define using insecure TLS with skipping certificate check.\n\n- `tls` - To enable SSL auth for Redis, set this to `enable`. If not set, TLS for Redis is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n    - parameter: tls\n      name: redis-streams-auth\n      key: tls\n    - parameter: ca\n      name: redis-streams-auth\n      key: ca\n    - parameter: cert\n      name: redis-streams-auth\n      key: cert\n    - parameter: key\n      name: redis-streams-auth\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n\n#### Using `streamLength`\n\nTo scale based on redis stream `XLEN` don't set `consumerGroup`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 20\n  cooldownPeriod: 200\n  maxReplicaCount: 10\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        streamLength: \"50\"\n```\n\n#### Using `lagCount`\n\nTo scale based on redis stream `XINFO GROUPS`, be sure to set `activationLagCount`. Example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        lagCount: \"10\"\n        activationLagCount: \"3\"\n```"
  },
  {
    "path": "content/docs/2.20/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars, SeleniumHQ\"\ncategory = \"Testing\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration with default values represent.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: ''  # Optional. Required to be matched with the request in queue and Node stereotypes (Similarly for `browserVersion` and `platformName`).\n      browserVersion: '' # Optional.\n      platformName: '' # Optional.\n      unsafeSsl: false # Optional.\n      activationThreshold: 0 # Optional.\n      nodeMaxSessions: 1 # Optional.\n      enableManagedDownloads: true # Optional.\n      capabilities: '' # Optional.\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info. If endpoint requires authentication, you can use `TriggerAuthentication` to provide the credentials instead of embedding in the URL.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `platformName` - Name of the browser platform. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `nodeMaxSessions` - Number of maximum sessions that can run in parallel on a Node. Update this parameter align with node config `--max-sessions` (`SE_NODE_MAX_SESSIONS`) to have the correct scaling behavior. (Default: `1`, Optional).\n- `enableManagedDownloads`- Set this for Node enabled to auto manage files downloaded for a given session on the Node. When the client requests enabling this feature, it can only be assigned to the Node that also enabled it. Otherwise, the request will wait until it timed out. (Default: `true`, Optional).\n- `capabilities` - Add more custom capabilities for matching specific Nodes. It should be in JSON string, see [example](https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes) (Optional)\n\n**Trigger Authentication**\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `authType` - Type of authentication to be used. This can be set to `Bearer` or `OAuth2` in case Selenium Grid behind an Ingress proxy with other authentication types. (Optional)\n- `accessToken` - Access token. This is required when `authType` is set a value. (Optional)\n\n### Example\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `platformNane` and empty `browserVersion`\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nNoted:\n- From `v2.16.1+`, the trigger metadata `browserVersion`, `platformName` is recommended to be set explicitly to have the correct scaling behavior (especially when your Grid includes autoscaling Nodes, non-autoscaling Nodes, relay Nodes, etc.). Besides that, in client binding, it is also recommended to set the `browserVersion`, `platformName` to align with the trigger metadata. Please see below examples for more details.\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser, which is created from client. For example in Python binding\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\nWith above script, the request is sent to Grid. Via GraphQL response, it looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 0,\n      \"totalSlots\": 0\n    },\n    \"nodesInfo\": {\n      \"nodes\": []\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nIn Node deployment spec, there is environment variable `SE_NODE_BROWSER_VERSION` which can be set to empty. This is used to unset `browserVersion` in Node stereotypes (it is in project [docker-selenium](https://github.com/SeleniumHQ/docker-selenium) setting short browser build number by default), which is expected to match with the request capabilities in queue and scaler trigger metadata.\n\nWhen the request capabilities match with scaler trigger metadata, the scaler will create a new Node and connect to the Hub. Now the GraphQL response looks like\n\n```json\n{\n  \"data\": {\n    \"grid\": {\n      \"sessionCount\": 0,\n      \"maxSession\": 1,\n      \"totalSlots\": 1\n    },\n    \"nodesInfo\": {\n      \"nodes\": [\n        {\n          \"id\": \"UUID-of-Node\",\n          \"status\": \"UP\",\n          \"sessionCount\": 0,\n          \"maxSession\": 1,\n          \"slotCount\": 1,\n          \"stereotypes\": \"[{\\\"slots\\\": 1, \\\"stereotype\\\": {\\\"browserName\\\": \\\"chrome\\\", \\\"browserVersion\\\": \\\"\\\", \\\"platformName\\\": \\\"Linux\\\"}}]\",\n          \"sessions\": []\n        }\n      ]\n    },\n    \"sessionsInfo\": {\n      \"sessionQueueRequests\": [\n        \"{\\\"browserName\\\": \\\"chrome\\\", \\\"platformName\\\": \\\"linux\\\"}\"\n      ]\n    }\n  }\n}\n```\n\nNow, the request can be picked up by the Node and the session is created. Session queue will be cleared and the scaler will not create a new Node until the next request comes in.\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `browserVersion` and `platformName`\n\nMoreover, at the same time, you can create one more scaled object for Chrome browser request with specific `browserVersion`. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome-131\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:131.0\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: '131.0'\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-131\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-131\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-131\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '131.0'\n        unsafeSsl: 'true'\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '131.0')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n#### Selenium Grid scaler trigger metadata with Node `enableManagedDownloads`\n\nIn image `selenium/node-chrome`, the environment variable `SE_NODE_ENABLE_MANAGED_DOWNLOADS` is used to append the `--enable-managed-downloads` CLI option to the Node. This option is used to enable the Node to auto manage files downloaded for a given session on the Node. The request with enabling this feature can only be assigned to the Node also enabled it, otherwise the request will be waited until request timed out.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # https://www.selenium.dev/documentation/grid/configuration/cli_options/#node\n          - name: SE_NODE_ENABLE_MANAGED_DOWNLOADS\n            value: \"true\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Scaler trigger param configuration should be aligned with Node stereotype.\n        enableManagedDownloads: \"true\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# https://www.selenium.dev/documentation/webdriver/drivers/remote_webdriver/#enable-downloads-in-the-grid\noptions.enable_downloads = True\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata with extra `capabilities`\n\nFor an advanced use case, you also can set custom capabilities for matching specific Nodes in the scaler trigger metadata. For example\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-chrome\n          image: selenium/node-chrome:132.0\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: '132.0'\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n          # Append custom capabilities to Node stereotype. See: https://github.com/SeleniumHQ/docker-selenium?tab=readme-ov-file#node-configuration-options\n          - name: SE_NODE_STEREOTYPE_EXTRA\n            value: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-chrome-132\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome-132\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome-132\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        browserVersion: '132.0'\n        unsafeSsl: 'true'\n        # Add custom capabilities for matching specific Nodes in scaler trigger metadata. See: https://github.com/kedacore/keda/pull/6536\n        capabilities: \"{\\\"myApp:version\\\":\\\"beta\\\", \\\"myApp:publish:\\\":\\\"public\\\"}\"\n```\n\nThe request to trigger this scaler should be\n\n```python\noptions = ChromeOptions()\noptions.set_capability('platformName', 'Linux')\noptions.set_capability('browserVersion', '132.0')\n# Add custom capabilities for matching specific Nodes in client binding. See: https://www.selenium.dev/documentation/grid/configuration/toml_options/#setting-custom-capabilities-for-matching-specific-nodes\noptions.set_capability('myApp:version', 'beta')\noptions.set_capability('myApp:publish', 'public')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Firefox browser\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-firefox\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-firefox\n          image: selenium/node-firefox:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-firefox\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-firefox\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-firefox\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = FirefoxOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Edge browser\n\nSimilarly, for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-edge\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n        - name: selenium-node-edge\n          image: selenium/node-edge:latest\n          ports:\n          - containerPort: 5555\n          env:\n          - name: SE_NODE_BROWSER_VERSION\n            value: ''\n          - name: SE_NODE_PLATFORM_NAME\n            value: 'Linux'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-scaledobject-edge\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-edge\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-edge\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n```\n\nRequest to trigger the scaler\n\n```python\noptions = EdgeOptions()\noptions.set_capability('platformName', 'Linux')\ndriver = webdriver.Remote(options=options, command_executor=SELENIUM_GRID_URL)\n```\n\n---\n#### Selenium Grid scaler trigger metadata for Chrome browser with `nodeMaxSessions`\n\nIn case you want to scale from 0 (`minReplicaCount: 0`), and browser nodes are configured different `--max-sessions` greater than 1, you can set `nodeMaxSessions` for scaler align with number of slots available per node to have the correct scaling behavior.\n\n```yaml\nkind: Deployment\nmetadata:\n  name: selenium-node-chrome\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  replicas: 1\n  template:\n    spec:\n      containers:\n      - name: selenium-node-chrome\n        image: selenium/node-chrome:latest\n        ports:\n        - containerPort: 5555\n        env:\n        - name: SE_NODE_BROWSER_VERSION\n          value: ''\n        - name: SE_NODE_PLATFORM_NAME\n          value: 'Linux'\n        - name: SE_NODE_OVERRIDE_MAX_SESSIONS\n          value: 'true'\n        - name: SE_NODE_MAX_SESSIONS\n          value: '4'\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        platformName: 'Linux'\n        nodeMaxSessions: 4\n        unsafeSsl: 'true'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n- `username` - Username for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n- `password` - Password for basic authentication in GraphQL endpoint instead of embedding in the URL. (Optional)\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n  graphql-username: base64 encoded value of GraphQL Username\n  graphql-password: base64 encoded value of GraphQL Password\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n  - parameter: username\n    name: selenium-grid-secret\n    key: graphql-username\n  - parameter: password\n    name: selenium-grid-secret\n    key: graphql-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-node-chrome\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-node-chrome\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n        platformName: 'Linux'\n        unsafeSsl: 'true'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/solace-pub-sub-dm.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker - Direct Messaging\"\navailability = \"2.18+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker - Direct Messaging\"\ngo_file = \"solace_dm_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-direct-messaging` trigger that scales based on a Solace PubSub+ Event Broker direct messaging rates for all the clients in a message vpn that matches a common client name prefix.\n\n> &#128161; **Note:**\nThis trigger is for **Direct messaging** only, it provides the ability to scale the number of client instances automatically based upon transient metrics for shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length), all this metrics exists as long as the clients are connected.\n\nIf you need to use **Guaranteed messaging** (Solace PubSub+ Event Broker queue) you should use the `solace-event-queue` trigger.\n\n```yaml\n  triggers:\n  - type: solace-direct-messaging\n    metricType: Value\n    metadata:\n      solaceSempBaseURL:  \"https://solace_broker1:943,https://solace_broker2:943\"\n      messageVpn: \"message-vpn\"\n      clientNamePattern: \"client-name-pattern\"\n      unsafeSSL: \"true\"\n      queuedMessagesFactor: '3'\n      aggregatedClientTxMsgRateTarget: '600'      \n      aggregatedClientTxByteRateTarget: '0'\n      aggregatedClientAverageTxByteRateTarget: '0'\n      aggregatedClientAverageTxMsgRateTarget: '0'\n      usernameFromEnv: 'ENV_VAR_USER'\n      passwordFromEnv: 'ENV_VAR_PWD'\n    authenticationRef:\n      name: trigger-authentication-ref\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Comma separated list of Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`. (Required)\n\n- `messageVpn` - Message VPN hosted on the Solace broker from which the metrics will be collected. (Required)\n\n- `clientNamePattern` - Client name pattern that will be used to identify the clients that are consuming from a shared subscription. (Required). It will be used to match all the client names that match the expression: **' \\*client-name-pattern\\* '**\n\n- `unsafeSSL` - Flag to enable unsafe host urls (self signed certificates). (Default:  `false`, Optional)\n\n- `queuedMessagesFactor` - Flag to to increase weight on queued messages (D-1) and scale faster to avoid discarding messages. (Default:  `3`, Optional)\n\n- `aggregatedClientTxMsgRateTarget` - Target number messages per second the clients in the shared subscription are expected to consume, if the actual aggregated messages per second number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientTxByteRateTarget` - Target number bytes per second the clients in the shared subscription are expected to consume, if the actual aggregated bytes per second number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientAverageTxByteRateTarget` - Target average number messages per minute the clients in the shared subscription are expected to consume, if the actual aggregated messages per minute number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `aggregatedClientAverageTxMsgRateTarget` - Target average number bytes per minute the clients in the shared subscription are expected to consume, if the actual aggregated bytes per minute number is greater the number of replicas will be increased. (Default: `0`, Optional)\n\n- `usernameFromEnv` - Environment variable set with SEMP user account. (Optional)\n\n- `passwordFromEnv` - Environment variable set with password for the user account. (Optional)\n\n**Parameter Requirements:**\n\n- Parameters resolving the target host and shared subscription are all **required:** `solaceSempBaseURL`, `messageVpn`, `clientNamePattern`\n\n- **At least** one of `aggregatedClientTxMsgRateTarget`, `aggregatedClientTxByteRateTarget`, `aggregatedClientAverageTxByteRateTarget` or  `aggregatedClientAverageTxMsgRateTarget` is **required**.\n\nIf more than one target values are present, calculation is done for each metric and the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n\nFor more details please see [Horizontal Pod Autoscaling - Algorithm details](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)\n\nThe `solace-direct-messaging` Scaler polls the Solace SEMP REST API to get transient metrics from connected clients. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the  trigger to function. \n\nThese values can be set in several different ways:\n  - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n  - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\nThe objects in the example below are declared in `namespace=solace`. It is not required to \ndo so. If you do define a namespace for the configuration objects, then they should all be declared \nin the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval:  3\n  cooldownPeriod:  60\n  #Always > 0 because is direct messaging!\n  minReplicaCount:  1\n  maxReplicaCount: 20\n  advanced:\n    restoreToOriginalReplicaCount: true\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n         #The stabilization window is used to restrict the flapping of replica count when the metrics used for scaling keep fluctuating.\n         #The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale.\n         #All desired states from the past 1 minutes (60secs) will be considered\n          stabilizationWindowSeconds: 60\n          #Policy (Pods) allows at most 1 replicas to be scaled down in 10 seconds.\n          policies:\n          - type:          Pods\n            value:         1\n            #Indicates the length of time in the past for which the policy must hold true\n            periodSeconds: 10\n        scaleUp:\n          stabilizationWindowSeconds: 0\n          #Policy (Pods) allows at most 3 replicas to be scaled up in 3 seconds.\n          policies:\n          - type:          Pods\n            value:         5\n            periodSeconds: 3\n          selectPolicy:    Max\n  triggers:\n  - type: solace-direct-messaging\n    #we don’t want to take the average of the given metric across all replicas, just the value\n    metricType: Value\n    metadata:\n      solaceSempBaseURL:  \"https://broker1.messaging.solace.cloud:943,https://broker2.messaging.solace.cloud:943\"\n      messageVpn: \"consumer_vpn\"\n      #all the clients that match this client name pattern will be considered for metric gathering\n      clientNamePattern: \"direct-messaging-simple\"\n      #to be able to use self signed certs\n      unsafeSSL: \"false\"\n      #to increase weight on queued messages and scale faster\n      #if there are messages queued means we are behind\n      queuedMessagesFactor: '3'\n      #Metrics\n      aggregatedClientTxMsgRateTarget: '600'      \n      aggregatedClientTxByteRateTarget: '0'\n      aggregatedClientAverageTxByteRateTarget: '0'\n      aggregatedClientAverageTxMsgRateTarget: '0'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD      \n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ncategory = \"Messaging\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n**Note:**\nThis trigger is for **Guaranteed messaging** (Solace PubSub+ Event Broker queue) only, it provides the ability to scale the number of client instances automatically based upon metrics for a Solace PubSub+ Event Broker queue.\n\nIf you need to use **Direct messaging**, shared subscriptions (transmitted message rate, transmitted bytes rate, D-1 queue length) you should use the `solace-direct-messaging` trigger.\n\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    messageReceiveRateTarget:           '50'        ### Messages/second over last 1 minute interval\n    activationMessageCountTarget:       '10'\n    activationMessageSpoolUsageTarget:  '5'         ### Megabytes (MB)\n    activationMessageReceiveRateTarget: '1'         ### Messages/second over last 1 minute interval\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint comma-separated host list in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target message count observed on a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target message spool backlog (data stored in a queue expressed in Megabytes) for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageReceiveRateTarget` - Target number of messages/second manageable by a replica.\n- `activationMessageReceiveRateTarget` - Target number of messages per second delivered to a queue for activating the scaler (scaling from 0->1 or 1->0 replicas). Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **solaceSempBaseURL** can contain either a single URL or a comma-separated list of URLs.  If multiple URLs are provided, the scaler will iterate over the list until it is both able to connect the broker successfully AND the broker's messageVpn is in the **UP** state.  All brokers in the list will share the same authentication configuration.  This feature was primarily added to support Solace's Disaster Recovery Replication feature.\n- **At least** one of `messageCountTarget`, `messageSpoolUsageTarget`, or `messageReceiveRateTarget` is **required.** If one or more values are present, the metric value resulting in the highest desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values can be set in several different ways:\n    - `username` and `password` may be set directly in the trigger metadata\n    - Use TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below.\n    - Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv` metadata fields. The values of these fields are the names of environment variables that must be available to the scaler at run-time.\n\n**Important Notes about Metric Configuration:**\n\n> &#128161; **Note:** `messageCountTarget` provides good reactivity to changes in demand based on the queue undelivered backlog. The monitored queue value from SEMPv2 is `collections.msgs.count`\n\n> &#128161; **Note:** `messageReceiveRateTarget` provides the ability to achieve consumer stability under constant load. The value monitored from SEMPv2 is `data.averageRxMsgRate`, which is the average message delivery rate to a queue over a one minute period.\n\n> &#128161; **Important:** For best results, both `messageCountTarget` and `messageReceiveRateTarget` should be specified to configure a Solace Scaler. A combined approach capitalizes on the best characteristics of each metric.\n\n> &#128161; **Note:** Configured by itself, `messageCountTarget` will make consumer scaling reactive but may introduce [flapping](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#flapping): the constant creation and destruction of replicas as the system tries to achieve a steady state.\n>> For example, a Solace consumer app scaled by KEDA experiences an increase in the rate of message delivery to its source queue, resulting in a backlog (high message count). Based on the `messageCountTarget`, KEDA increases the number of replicas and the backlog is cleared. With the backlog reduced, KEDA scales-in the application, reducing the number of replicas. If the rate of message delivery remains high, the application may not be able to maintain the backlog with the lower number of replicas, causing KEDA to scale-out the workload again. The backlog is again cleared - and the pattern repeats. Using the `messageReceiveRateTarget` as an additional metric can be used to identify a suitable replica count to handle the inbound message rate while keeping the backlog clear and the application performant.\n\n> &#128161; **Note:** Configured by itself, `messageReceiveRateTarget` cannot scale consumers based on queue backlog.\n\n> &#128161; **Activation Values:** `activationMessageCountTarget`, `activationMessageSpoolUsageTarget`, and `activationMessageReceiveRateTarget` are assumed to be `0` (zero) if not specified.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      ## Connection Details\n      solaceSempBaseURL:        http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:               test_vpn\n      queueName:                SCALED_CONSUMER_QUEUE1\n      ## Scaler Details, average values per replica\n      messageCountTarget:       '50'\n      messageSpoolUsageTarget:  '100000'\n      messageReceiveRateTarget: '20'\n      ## Activation - Scale from 0 replicas to active workload if one of the conditions is met\n      activationMessageCountTarget:        '5'\n      activationMessageSpoolUsageTarget:   '2'\n      activationMessageReceiveRateTarget:  '5'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/solarwinds.md",
    "content": "+++\ntitle = \"SolarWinds\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics from SolarWinds.\"\ngo_file = \"solarwinds_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solarwinds` trigger that scales based on metrics from SolarWinds.\n\n```yaml\ntriggers:\n- type: solarwinds\n  metadata:\n    host: https://api.na-01.cloud.solarwinds.com\n    targetValue: \"1\"\n    activationValue: \"3\"\n    metricName: \"k8s.pod.cpu.usage.seconds.rate\"\n    aggregation: \"AVG\"\n    intervalS: \"60\"\n    filter: \"k8s.deployment.name:my-deployment\"\n```\n\n**Parameter list:**\n\n- `host` - The SolarWinds API endpoint. (Example: `https://api.na-01.cloud.solarwinds.com`)\n- `targetValue` - Value to reach to start scaling. (This value can be an integer or float)\n- `activationValue` - Target value for activating the scaler. (Optional, Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds))\n- `metricName` - The name of the metric to monitor.\n- `aggregation` - The aggregation method to use. (Values: `COUNT`, `MIN`, `MAX`, `AVG`, `SUM`, `LAST`)\n- `intervalS` - The interval in seconds for the metric collection.\n- `filter` - The filter to apply to the metric data. (Optional, Examples below)\n  - `key1:value1 key2:value2` - Search using key values pairs with a delimiting space for an implicit AND\n  - `key:[value1,value2]` - Search using IN operator (key equals value1 or value2)\n  - `key:~value` - Search using CONTAINS operator\n  - `key>value1 key<value2` - Use comparative operators for number based keys such as (“=”, “>”, “<“, “<=”, “>=”) (key between value1 and value2)\n  - `NOT key:\"\"` - Search using NOT operator and EMPTY value (key is not empty)\n  - `entities(attribute:value)` - search using attributes of entities related to the metric data (metric values associated with entity having attribute equals value)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing the necessary credentials.\n\n**Credential based authentication:**\n\n- `apiToken` - The API token for accessing SolarWinds Observability. See [doc](https://documentation.solarwinds.com/en/success_center/observability/content/settings/api-tokens.htm) for more information.\n\n### Example\n\nHere is an example of a SolarWinds Scaler with authentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solarwinds-secret\n  namespace: default\ndata:\n  apiToken: <base64-encoded-api-token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solarwinds-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiToken\n      name: solarwinds-secret\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solarwinds-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: nginx\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 2\n  triggers:\n  - type: solarwinds\n    authenticationRef:\n      name: solarwinds-auth\n    metadata:\n      host: https://api.na-01.cloud.solarwinds.com\n      targetValue: \"3\"\n      activationValue: \"3\"\n      metricName: \"k8s.pod.cpu.usage.seconds.rate\"\n      aggregation: \"AVG\"\n      intervalS: \"60\"\n      filter: \"k8s.deployment.name:my-deployment\"\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/solr.md",
    "content": "+++\ntitle = \"Solr\"\navailability = \"v2.11+\"\nmaintainer = \"Community\"\ncategory = \"Metrics\"\ndescription = \"Scale applications based on Solr query results.\"\ngo_file = \"solr_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the solr trigger that scales based on the outputs of a Solr query.\n\n```yaml\ntriggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue : \"3\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the Solr service.\n- `query`- A Solr query that should return single numeric value. (Default: `*:*`, Optional)\n- `collection` - Your collection name on Solr.\n- `targetQueryValue` - A threshold that is used as targetValue or targetAverageValue (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via TriggerAuthentication configuration.\n\n**Credential based authentication:**\n\n- `username` - Username for configured user to login to the Solr instance.\n- `password` - Password for configured user to login to the Solr instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: solr-secret\ntype: Opaque\ndata:\n  solr_username: SOLR_USERNAME\n  solr_password: SOLR_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-solr\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: solr-secret\n    key: solr_username\n  - parameter: password\n    name: solr-secret\n    key: solr_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: solr-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deploy        \n  triggers:\n  - type: solr\n    metadata:\n      host: \"http://solr-service.solr-ns.svc.cluster.local:8983\"\n      query: \"*:*\"\n      collection: \"my_core\"\n      targetQueryValue: \"1\"\n    authenticationRef:\n      name: trigger-auth-solr\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/splunk-observability.md",
    "content": "+++\ntitle = \"Splunk Observability\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk Observability Cloud metrics.\"\ngo_file = \"splunk_observability_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk-observability` trigger that scales based on the result of a metric series queried from the Splunk Observability Cloud platform with a [SignalFlow query](https://dev.splunk.com/observability/docs/signalflow/).\n\n\n```yaml\ntriggers:\n  - type: splunk-observability\n    metadata:\n      # Required: SignalFlow query to retrieve the desired metric time series\n      query: \"data('demo.trans.latency').max().publish()\"\n      # Required: Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds\n      duration: \"10\"\n      # Required: Threshold to reach to start scaling\n      targetValue: \"400.1\"\n      # Required: Target value for activating the scaler\n      activationTargetValue: \"1.1\"\n      # Required: Specifies how the Metrics Time Series should be processed, options are \"min\" (minimum value), \"max\" (maximum value), and \"avg\" (average value)\n      queryAggregator: \"avg\"\n```\n\n**Parameter list:**\n\n- `query` - SignalFlow query for querying the desired metrics.\n- `duration` - Duration of the stream being created to query a Metric Time Series (MTS) from Splunk Observability Cloud. The specified duration is in seconds.\n- `targetValue` - Threshold to reach to start scaling.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `queryAggregator` - When querying metrics from Splunk Observability Cloud, initially a Metric Time Series (MTS) is returned, a list consisting of several datapoints. The 'queryAggregator' specifies how this series of metrics should be \"rolled up\". Valid values for this field are \"avg\", which returns the average, \"min\", which returns the minimum of the metrics in the series, and \"max\", which returns the maximum value.\n\n**Parameter list:**\n\n- `accessToken` - Splunk Observability Cloud Access Token.\n- `realm` - Splunk Observability Cloud Realm.\n\n## Configuration Example\n\nThe following example shows how to scale a simple NGINX employment with the help of KEDA and the Splunk Observability Cloud scaler:\n\n#### Simple NGINX employment\n\n```yaml\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n        - name: nginx\n          image: nginx:1.14.2\n          ports:\n            - containerPort: 80\n```\n\n#### Authentication\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-secrets\ndata:\n  accessToken: <base64-encoded Splunk Observability Cloud Access Token>\n  realm: <base64-encoded Splunk Observability Cloud Realm>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-splunk-secret\nspec:\n  secretTargetRef:\n    - parameter: accessToken\n      name: splunk-secrets\n      key: accessToken\n    - parameter: realm\n      name: splunk-secrets\n      key: realm\n```\n\n#### KEDA Scaler\n\n```yaml\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: keda\nspec:\n  scaleTargetRef:\n    apiVersion: apps/v1\n    kind: Deployment\n    name: nginx\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n    - type: splunk-observability\n      metricType: Value\n      metadata:\n        query: \"data('demo.trans.count', filter=filter('demo_host', 'server6'), rollup='rate').sum(by=['demo_host']).publish()\"\n        duration: \"10\"\n        queryValue: \"400.1\"\n        activationQueryValue: \"1.1\"\n        queryAggregator: \"max\" # 'min', 'max', or 'avg'\n      authenticationRef:\n        name: keda-trigger-auth-splunk-secret\n```"
  },
  {
    "path": "content/docs/2.20/scalers/splunk.md",
    "content": "+++\ntitle = \"Splunk\"\navailability = \"v2.15+\"\nmaintainer = \"Community\"\ncategory = \"Data & Storage\"\ndescription = \"Scale applications based on Splunk saved search results.\"\ngo_file = \"splunk_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `splunk` trigger that scales based on the result of a [saved search](https://docs.splunk.com/Documentation/Splunk/9.2.1/Search/Savingsearches).\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: splunk\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"1\"\n      activationValue: \"10\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n**Parameter list:**\n\n- `host` - Search API host and port. Example: `https://localhost:8089`.\n- `unsafeSsl` - Whether to trust invalid certificates or not. (Values: `\"true\"`, `\"false\"`, Default: `\"false\"`, Optional)\n- `targetValue` - Value to reach to start scaling (This value can be a integer or float).\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).\n- `savedSearchName` - Name of saved search that returns metric data for scaling.\n- `valueField` - The name of the field in the search results containing the metric value. Example: `index=_internal | tail | stats count`, the `valueField` is `count`.\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or an API token. You will need to use `TriggerAuthentication` CRD to configure the authentication.\n\n> **Note:**\n>\n> `TriggerAuthentication` is required to use this scaler due to the hard requirement of providing a `username` for the Splunk API.\n\n**Parameter list:**\n\n- `username` - Splunk username authorized to access the search API.\n- `apiToken` - Splunk API token for supplied `username`. Conflicts with `password`.\n- `password` - Password for supplied `username`. Conflicts with `apiToken`.\n\nThe user will need access to the saved search.\n\n### Examples\n\n### Username/password\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### API Token\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # admin\n  apiToken: <base64 encoded api token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: apiToken\n      name: splunk-creds\n      key: apiToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      targetValue: \"11\"\n      activationValue: \"15\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n\n### Full example using Splunk deployment\n\n```yaml\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: splunkconf\ndata:\n  default.yml: |\n    splunk:\n      conf:\n        - key: savedsearches\n          value:\n            directory: /opt/splunk/etc/users/admin/search/local\n            content:\n              my-saved-search-name:\n                action.email.useNSSubject: 1\n                action.webhook.enable_allowlist: 0\n                alert.track: 0\n                cron_schedule: '*/1 * * * *'\n                dispatch.earliest_time: -15m\n                dispatch.latest_time: now\n                display.general.type: statistics\n                display.page.search.tab: statistics\n                display.visualizations.show: 0\n                enableSched: 1\n                request.ui_dispatch_app: search\n                request.ui_dispatch_view: search\n                search: index=_internal | tail | stats count\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: splunk-creds\ndata:\n  username: YWRtaW4= # \"admin\"\n  password: cGFzc3dvcmQ= # \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: splunk-auth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: splunk-creds\n      key: username\n    - parameter: password\n      name: splunk-creds\n      key: password\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: splunk\nspec:\n  ports:\n    - port: 8000\n      targetPort: web\n      name: web-svc\n    - port: 8089\n      targetPort: 8089\n      name: api-svc\n  selector:\n    app: splunk\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: splunk\n  namespace: default\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: splunk\n  template:\n    metadata:\n      labels:\n        app: splunk\n    spec:\n      containers:\n      - name: splunk\n        image: splunk/splunk:9.2\n        ports:\n          - containerPort: 8000\n            name: web\n          - containerPort: 8089\n            name: api\n        env:\n          - name: SPLUNK_START_ARGS\n            value: --accept-license\n          - name: SPLUNK_PASSWORD\n            value: password\n        volumeMounts:\n          - name: splunkconf-volume\n            mountPath: /tmp/defaults\n      volumes:\n        - name: splunkconf-volume\n          configMap:\n            name: splunkconf\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: nginx\nspec:\n  selector:\n    matchLabels:\n      app: nginx\n  replicas: 1\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx\n        ports:\n        - containerPort: 8080\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: splunk-scaledobject\nspec:\n  pollingInterval: 15\n  minReplicaCount: 1\n  maxReplicaCount: 3\n  scaleTargetRef:\n    name: nginx\n  triggers:\n  - type: splunk\n    authenticationRef:\n      name: splunk-auth\n    metadata:\n      host: https://splunk.default.svc.cluster.local:8089\n      unsafeSsl: \"true\"\n      targetValue: \"5\"\n      activationValue: \"5\"\n      savedSearchName: my-saved-search-name\n      valueField: count\n```\n"
  },
  {
    "path": "content/docs/2.20/scalers/sumologic.md",
    "content": "+++\ntitle = \"Sumo Logic\"\navailability = \"v2.18+\"\nmaintainer = \"Community\"\ncategory = \"Monitoring & Analytics\"\ndescription = \"Scale applications based on Sumo Logic logs searches and metrics queries.\"\ngo_file = \"sumologic_scaler\"\n+++\n\n## Trigger Specification\n\nThis specification describes the `sumologic` trigger that scales based on Sumo Logic logs searches and metrics queries. The scaler supports three different query types:\n\n- **`logs`** - Scale based on Sumo Logic logs query results\n- **`metrics`** - Scale based on single Sumo Logic metrics query results  \n- **`metrics` (multi-query)** - Scale based on multiple combined Sumo Logic metrics queries\n\nHere are examples of the different trigger configurations:\n\n**Logs Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"   # Sumo Logic API endpoint\n    queryType: \"logs\"                   # Type must be \"logs\"\n    query: \"_view=my_view | count\"      # Your Sumo Logic logs query\n    resultField: \"_count\"               # Field to extract value from\n    timerange: \"15m\"                    # Lookback window\n    timezone: \"Asia/Kolkata\"            # Timezone (e.g., Asia/Kolkata)\n    queryAggregator: \"Max\"              # Aggregation method: Latest, Avg, Sum, Count, Min, Max\n    threshold: \"1000\"                   # Threshold for scaling\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Single Metrics Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"\n    queryType: \"metrics\"\n    query: \"metric=cpu.usage | avg\"\n    quantization: \"15s\"\n    rollup: \"Max\"\n    timerange: \"15m\"\n    timezone: \"Asia/Kolkata\"\n    queryAggregator: \"Max\"\n    threshold: \"50\"\n    maxRetries: \"3\"                     # Optional: Maximum retry attempts\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Multi-Metrics Query Example:**\n```yaml\ntriggers:\n- type: sumologic\n  metadata:\n    host: \"https://api.sumologic.com\"\n    queryType: \"metrics\"\n    query.A: \"metric=requests_total | rate\"\n    query.B: \"metric=request_capacity\"\n    query.C: \"(#A / #B) * 100 along service\"\n    resultQueryRowID: \"C\"          # Which query result to extract\n    quantization: \"15s\"\n    rollup: \"Max\"\n    timerange: \"15m\"\n    timezone: \"Asia/Kolkata\"\n    queryAggregator: \"Max\"\n    threshold: \"75\"\n  authenticationRef:\n    name: keda-trigger-auth-sumologic\n```\n\n**Parameter list:**\n\n**Common Parameters:**\n\n- `host` - Sumo Logic API endpoint URL (Based on your Geo).\n- `queryType` - Type of query. (Values: `logs`, `metrics`)\n- `query` - Sumo Logic query (for single queries).\n- `timerange` - Time range to evaluate the query.\n- `timezone` - Timezone for query execution. (Default: `UTC`, Optional)\n- `queryAggregator` - Aggregation method. (Values: `Latest`, `Avg`, `Sum`, `Count`, `Min`, `Max`, Default: `Avg`, Optional)\n- `threshold` - Target value for scaling.\n- `maxRetries` - Maximum number of retry attempts for API requests. (Default: `3`, Optional)\n\n**Logs Query Specific Parameters:**\n\n- `resultField` - Field from query results to extract the scaling metric. (Required when `queryType` is `logs`)\n- `logsPollingInterval` - Polling interval for log search job. (Default: `1s`, Optional)\n\n**Metrics Query Specific Parameters:**\n\n- `quantization` - Granularity of data points. (Required when `queryType` is `metrics`)\n- `rollup` - Metrics rollup type. (Values: `Avg`, `Sum`, `Min`, `Max`, `Count`, Default: `Avg`, Optional)\n\n**Multi-Metrics Query Specific Parameters:**\n\n- `query.A`, `query.B`, `query.C` etc - Multi-stage queries, where later queries can refer to earlier ones. (Required for multi-metrics queries)\n- `resultQueryRowID` - Which final query (`A`, `B`, `C`, etc.) to use for scaling. (Required for multi-metrics queries)\n\n## Authentication Parameters\n\nYou must configure a `TriggerAuthentication` resource to authenticate with Sumo Logic.\n\n**Prerequisites:**\n- A Sumo Logic Access ID and Access Key\n\nAuthentication is handled through a Kubernetes `Secret` combined with a `TriggerAuthentication`:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: sumologic-auth-secret\ndata:\n  accessID: <base64-encoded-accessID>\n  accessKey: <base64-encoded-accessKey>\n\n---\n\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-sumologic\nspec:\n  secretTargetRef:\n    - parameter: accessID\n      name: sumologic-auth-secret\n      key: accessID\n    - parameter: accessKey\n      name: sumologic-auth-secret\n      key: accessKey\n```\n\n### Example\n\nHere is a complete example that demonstrates autoscaling based on Sumo Logic logs query:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: sumologic-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: sumologic\n    metadata:\n      host: \"https://api.sumologic.com\"\n      queryType: \"logs\"\n      query: \"_view=error_logs | count\"\n      resultField: \"_count\"\n      timerange: \"5m\"\n      threshold: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-sumologic\n```\n\n### Notes\n\n- `pollingInterval` controls how often KEDA polls Sumo Logic.\n- `cooldownPeriod` controls how long KEDA waits before scaling down.\n- `MetricType:` The scaler supports both `AverageValue` and `Value` metric types.\n- Ensure that the Sumo Logic user has **appropriate access** to the queries being executed.\n\n"
  },
  {
    "path": "content/docs/2.20/scalers/temporal.md",
    "content": "+++\ntitle = \"Temporal\"\navailability = \"v2.17+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Temporal task queue.\"\ngo_file = \"temporal_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `temporal` trigger that scales based on a Temporal task queue.\n\n```yaml\ntriggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n      queueTypes: workflow # optional\n      buildId: 1.0.0 # optional\n      selectAllActive: \"false\" # optional\n      selectUnversioned: \"false\" # optional\n      minConnectTimeout: \"5\" # optional\n      unsafeSsl: \"false\" # optional\n      tlsServerName: \"custom-tls-servername\" # optional\n```\n\n**Parameter list:**\n\n- `endpoint` - This parameter specifies the URL of the Temporal gRPC service. You need to provide the service address in the format `<hostname>:<port>`. (Required)\n- `endpointFromEnv` - Defines the endpoint, similar to the `endpoint` parameter, but the value is read from an environment variable. (Optional)\n- `namespace` - The namespace of the temporal service. (Default:`default`, Optional)\n- `activationTargetQueueSize` - This sets the target value for activating the scaler. More information about activation thresholds can be found  [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `5`, Optional)\n- `taskQueue` - This parameter specifies the task queue name. (Required)\n- `queueTypes` - Task Queue type can be configured as `workflow`, `activity`, or both, separated by a comma (,) if multiple types are needed. (Default: `workflow`, Optional)\n- `buildId` - Build IDs identify Worker versions for Workflow versioning and task compatibility (Optional)\n- `selectAllActive` - Include all active versions (Default:`false`, Optional)\n- `selectUnversioned` - Include the unversioned queue (Default:`false`, Optional)\n- `apiKeyFromEnv` - API key for authentication similar to `apiKey`, but read from an environment variable (Optional)\n- `minConnectTimeout` - This is the minimum amount of time we are willing to give a connection to complete. (Default:`5`, Optional)\n- `unsafeSsl` - Whether to allow unsafe SSL (Default: `false`, Optional)\n- `tlsServerName` - The custom tls server name (Optional)\n\n> 💡 **NOTE:** Activation based on backlog may not be reliable when scaling to zero.\n  This approach fails to account for in-flight tasks or workloads with throughput too low to trigger a backlog.\n  Consequently, scaling to zero could result in undesirable behavior,\n  such as terminating resources and subsequently having to scale back up to handle queued tasks. To address these challenges, consider customizing the cooldownPeriod or scale-down behavior of the Horizontal Pod Autoscaler (HPA).\n  By fine-tuning the configurations, you can prevent premature scaling to zero,\n  ensuring that resources remain available for in-flight tasks or workloads with minimal throughput.\n\n\n**Authentication Parameters:**\n\nTemporal supports `apiKey` and `mTLS` for authentication. You can use the following parameters to configure authentication:\n\n- `apiKey` - API key for authentication with temporal cloud. (Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the keyPassword is used to decrypt the provided key. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: temporal-secret\n  namespace: default\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-temporal\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: apiKey\n    name: temporal-secret\n    key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: workload-scaledobject\n  pollingInterval: 5\n  cooldownPeriod:  10\n  minReplicaCount: 0\n  maxReplicaCount: 5\n  advanced:\n    horizontalPodAutoscalerConfig:\n      behavior:\n        scaleDown:\n          stabilizationWindowSeconds: 10\n  triggers:\n  - type: temporal\n    metadata:\n      namespace: default\n      taskQueue: \"workflow_with_single_noop_activity:test\"\n      targetQueueSize: \"2\"\n      activationTargetQueueSize: \"0\"\n      endpoint: temporal-frontend.temporal.svc.cluster.local:7233\n    authenticationRef:\n      name: keda-trigger-auth-temporal\n```\n"
  },
  {
    "path": "content/docs/2.20/setupscaler.md",
    "content": "+++\ntitle = \"Setup Autoscaling with KEDA\"\nweight = 500\ndescription = \"Procedure to Setup a Scaler in KEDA\"\n+++\n\n## Prerequisites\n\n1. **Kubernetes Cluster**:\n   - Ensure you have a running Kubernetes cluster set up and accessible.\n   - If you don't have a cluster yet, follow the [official Kubernetes documentation](https://kubernetes.io/docs/setup/) to create a new cluster suitable for your environment (local machine, cloud provider, etc.).\n\n2. **KEDA Installation**:\n   - KEDA needs to be installed on your Kubernetes cluster before you can use it.\n   - Follow the [KEDA installation guide](../deploy/) carefully, including any prerequisites specific to your Kubernetes setup.\n   - The installation guide provides instructions for different installation methods (e.g., YAML, Helm charts, etc.). Choose the method that suits your needs.\n\n3. **kubectl**:\n   - The `kubectl` command-line tool is required to interact with your Kubernetes cluster.\n   - Follow the [official kubectl installation guide](https://kubernetes.io/docs/tasks/tools/#kubectl) to install `kubectl` on your operating system.\n   - Once installed, configure `kubectl` to communicate with your Kubernetes cluster by following the cluster-specific instructions provided by your Kubernetes setup.\n\n## Step 1: Identify the Scaler You Need\n\nKEDA supports various scalers that correspond to different event sources or triggers. Determining the right scaler is crucial for scaling your application based on the desired event source.\n\n1. Visit the [KEDA Scalers documentation](../scalers/) and browse through the list of available scalers.\n2. Identify the scaler that matches the event source you want to use for scaling your application. For example:\n   - If you want to scale based on incoming HTTP traffic, you would need the [HTTP Add-on](https://kedacore.github.io/http-add-on/).\n\n     > **Note:**\n     > The HTTP Add-on is still in beta stage and may not provide the full functionality or stability expected in a production environment.\n\n   - If you want to scale based on messages in a RabbitMQ queue, you would need the **RabbitMQ scaler**.\n   - If you want to scale based on a cron schedule, you would need the **Cron scaler**.\n3. Open the documentation page for your chosen scaler and familiarize yourself with its specific requirements and configuration options.\n\n## Step 2: Install the Required Scaler (if needed)\n\nSome scalers are part of the core KEDA installation, while others need to be installed separately as add-ons.\n\n1. Refer to the documentation of your chosen scaler to check if it needs to be installed separately.\n2. If the scaler needs to be installed separately, follow the installation instructions provided in the scaler's documentation carefully.\n   - The installation process typically involves running a command (e.g., `helm install` for Helm charts) or applying YAML manifests using `kubectl`.\n3. Verify that the scaler has been installed successfully by checking the output of the installation process or by running any provided verification commands.\n\n## Step 3: Create a ScaledObject Configuration File\n\nKEDA uses a custom resource called `ScaledObject` to define how your application should be scaled based on the chosen event source or trigger.\n\n1. Create a new file (e.g., `scaledobject.yaml`) in a text editor or using the command line.\n2. Define the `ScaledObject` configuration in this file, following the structure and examples provided in the documentation of your chosen scaler.\n3. Typically, the `ScaledObject` configuration includes the following sections:\n   - `metadata`: Specifies the name and namespace for the `ScaledObject`.\n   - `spec.scaleTargetRef`: Identifies the Kubernetes deployment or other resource that should be scaled.\n   - `spec.pollingInterval` (optional): Specifies how often KEDA should check for scaling events (defaults to 15 seconds).\n   - `spec.cooldownPeriod` (optional): Specifies the cool-down period in seconds after a scaling event (defaults to 300 seconds).\n   - `spec.maxReplicaCount` (optional): Specifies the maximum number of replicas to scale up to (defaults to 100).\n   - `spec.triggers`: Defines the specific configuration for your chosen scaler, including any required parameters or settings.\n4. Refer to the scaler's documentation for detailed explanations and examples of the `triggers` section and any other required or optional configuration settings.\n5. Save the `scaledobject.yaml` file after making the necessary modifications.\n\n## Step 4: Apply the ScaledObject Configuration\n\nOnce you have created the `ScaledObject` configuration file, apply it to your Kubernetes cluster using `kubectl`:\n\n1. Open a terminal or command prompt and navigate to the directory containing the `scaledobject.yaml` file.\n2. Run the following command to apply the `ScaledObject` configuration:\n\n   ```bash\n   kubectl apply -f scaledobject.yaml\n   ```\n\n   ```plaintext\n   scaledobject.keda.sh/<scaled-object-name> created\n   ```\n\n3. Verify that the `ScaledObject` has been created successfully by running:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This should display the `ScaledObject` you just created.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\nAfter applying the `ScaledObject` configuration, KEDA will start monitoring the specified event source and scale your application accordingly, based on the configurations you provided.\n\n## Step 5: Monitor Scaling Events\n\nYou can monitor the scaling events and logs generated by KEDA using the following commands:\n\n1. List all `ScaledObjects` in your cluster:\n\n   ```bash\n   kubectl get scaledobjects\n   ```\n\n   This will show you the current state of your `ScaledObject` and the number of replicas.\n\n   ```plaintext\n   NAME              SCALETARGETKIND   SCALETARGETNAME   MIN   MAX   TRIGGERS   AUTHENTICATION   READY   ACTIVE   FALLBACK   AGE\n   <scaled-object-name>   Deployment        <deployment-name>   1     10    cpu                    <none>            True    False    <none>      10s\n   ```\n\n2. View the logs of the KEDA operator:\n\n   ```bash\n   kubectl logs -n keda -l app=keda-operator\n   ```\n\n   The KEDA operator logs will show you detailed information about scaling events, decisions made by KEDA based on the event source, and any errors or warnings.\n\n   ```plaintext\n   {\"level\":\"info\",\"ts\":<timestamp>,\"logger\":\"scalehandler\",\"msg\":\"Successfully scaled deployment\",\"scaledobject.Namespace\":\"<namespace>\",\"scaledobject.Name\":\"<scaled-object-name>\",\"scaler\":<scaler-type>}\n   ```\n"
  },
  {
    "path": "content/docs/2.20/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.3/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.3/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.3/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.3/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam  # Optional. Default: none\n  secretTargetRef:                                    # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {secret-name}                               # Required.\n    key: {secret-key-name}                            # Required.\n  env:                                                # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {env-name}                                  # Required.\n    containerName: {container-name}                   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                     # Optional.\n    address: {hashicorp-vault-address}                # Required.\n    authentication: token | kubernetes                # Required.\n    role: {hashicorp-vault-role}                      # Optional.\n    mount: {hashicorp-vault-mount}                    # Optional.\n    credential:                                       # Optional.\n      token: {hashicorp-vault-token}                  # Optional.\n      serviceAccount: {path-to-service-account-file}  # Optional.\n    secrets:                                          # Required.\n    - parameter: {scaledObject-parameter-name}        # Required.\n      key: {hashicorp-vault-secret-key-name}           # Required.\n      path: {hashicorp-vault-secret-path}              # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.3/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interfaces:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nFew things to notice:\n\n- Lack of `Close` method as the GRPC connection defines the lifetime of the scaler\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\nFor `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.3/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval: 30                                # Optional. Default: 30 seconds\n  cooldownPeriod:  300                               # Optional. Default: 300 seconds\n  minReplicaCount: 0                                 # Optional. Default: 0\n  maxReplicaCount: 100                               # Optional. Default: 100\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n```yaml\n  minReplicaCount: 0   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well. KEDA will not enforce that value, meaning you can manually scale the resource to 0 and KEDA will not scale it back up. However, when KEDA itself is scaling the resource it will respect the value set there.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource.\n\n---\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.3/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state, for example a that has not finished yet **and** the underlying pod is either not running or has not completed yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) && !e.isAnyPodRunningOrCompleted(&job) {\n>\t\t\tpendingJobs++\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n"
  },
  {
    "path": "content/docs/2.3/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.3/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster you can run one of the following:\n\n```sh\nhelm uninstall keda -n keda\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.3.0`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.3.0/keda-2.3.0.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.3.0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.3.0 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.3.0`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.3.0/keda-2.3.0.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.3.0.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.3.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```"
  },
  {
    "path": "content/docs/2.3/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.3/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.3/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.3/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n"
  },
  {
    "path": "content/docs/2.3/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.3 has been tested on Kubernetes v1.16.0 or above.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.This is only supported as of KEDA v2.6 if you are using our Helm chart.                                                                                    |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable to your desired timeout in milliseconds. For example, on Linux/Mac/Windows WSL2 operating systems, you'd use this command to set to 1 second:\n\n```shell\nexport KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAnd on Windows Powershell, you'd use this command:\n\n```shell\n$env:KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAll applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported.\n"
  },
  {
    "path": "content/docs/2.3/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                               | Type      | Description                                                                                                                 |\n|-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                 | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                    | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`           | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`              | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`               | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                  | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                  | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`        | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                   | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`        | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`      | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded` | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                                   |\n| `ClusterTriggerAuthenticationDeleted`| `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                                     |\n"
  },
  {
    "path": "content/docs/2.3/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.3/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.3/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed the number of partitions on a topic.\n That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag.\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.3/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName\n    dimensionName: QueueName\n    # Required: Dimension Value - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Metric Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/docs/2.3/concepts/authentication/).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets       # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n\n> For the purposes of scaling, \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing.\n\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `\"\"`)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric which can be found in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Optionsinclude `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: kube_pod_status_ready\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Required - Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolID` - Id of the queue.\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on of the `blobContainerName`, `blobPrefix` and `blobDelimiter`. For example: **azure-blob-functions-blob-myprefix-example**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.3/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Password Authentication:**\n\n- `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager.\n- `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a  metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a  metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a  metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `password` - Password for the configured user to login to MongoDB server.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. The default for MSSQL is 1433.\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the `database` value (if specified), or the `host` value, or will be in the form `mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment\n variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: 1250 #required\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application.\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.3/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Metric name to use.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100\" # message backlog or publish/sec. target per instance\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.3/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.3/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.4/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.4/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.4/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.4/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam  # Optional. Default: none\n  secretTargetRef:                                    # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {secret-name}                               # Required.\n    key: {secret-key-name}                            # Required.\n  env:                                                # Optional.\n  - parameter: {scaledObject-parameter-name}          # Required.\n    name: {env-name}                                  # Required.\n    containerName: {container-name}                   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                     # Optional.\n    address: {hashicorp-vault-address}                # Required.\n    authentication: token | kubernetes                # Required.\n    role: {hashicorp-vault-role}                      # Optional.\n    mount: {hashicorp-vault-mount}                    # Optional.\n    credential:                                       # Optional.\n      token: {hashicorp-vault-token}                  # Optional.\n      serviceAccount: {path-to-service-account-file}  # Optional.\n    secrets:                                          # Required.\n    - parameter: {scaledObject-parameter-name}        # Required.\n      key: {hashicorp-vault-secret-key-name}           # Required.\n      path: {hashicorp-vault-secret-path}              # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.4/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a GRPC service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\nWant to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nBuilt-in scalers implement one of the following go interfaces:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval` defined in the ScaledObject/ScaledJob CRDs and scaling to 1 happens if this returns true.\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds `Run` method. The `Run` method receives a push channel (`active`), that the scaler can push `true` to any time to force scaling action independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the following GRPC contract [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto):\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nFew things to notice:\n\n- Lack of `Close` method as the GRPC connection defines the lifetime of the scaler\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\nFor example the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a connection to `service-address.svc.local:9090` and calls `IsActive`, `StreamIsActive`, and `GetMetricsSpec` with the following `ScaledObjectRef`\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\nFor `StreamIsActive` KEDA establishes the connection to the GRPC server and expects `IsActive` events to be streamed as a response.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler:\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project:\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata. This section implements an external scaler that queries earthquakes from https://earthquake.usgs.gov/ and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day\n\n`ScaledObject`\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`main.go`\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\nFull implementation can be found here: https://github.com/kedacore/external-scaler-samples\n\n`Services/ExternalScalerService.cs`\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n`index.js`\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to push `IsActiveResponse` whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.4/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Must be less than minReplicaCount\n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n\n```yaml\n  idleReplicaCount: 0   # Optional. Must be less than minReplicaCount\n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It is **not** supported by the CPU & memory scalers and will assume that fallback is disabled in those cases. This is because it only supports scalers that present their target as an `AverageValue` metric.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n\n---\n\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:**There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.4/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n\n"
  },
  {
    "path": "content/docs/2.4/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.4/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects,scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.4.0`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.4.0/keda-2.4.0.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.4.0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.4.0 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.4.0`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.4.0/keda-2.4.0.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.4.0.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.4.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.4/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.4/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.4/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.4/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n"
  },
  {
    "path": "content/docs/2.4/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.4 has been tested on Kubernetes v1.16.0 or above.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.This is only supported as of KEDA v2.6 if you are using our Helm chart.                                                                                    |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable to your desired timeout in milliseconds. For example, on Linux/Mac/Windows WSL2 operating systems, you'd use this command to set to 1 second:\n\n```shell\nexport KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAnd on Windows Powershell, you'd use this command:\n\n```shell\n$env:KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAll applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag   | Client Config Setting | Default Value | Description                                                    |\n| -------------- | --------------------- | ------------- | -------------------------------------------------------------- |\n| kube-api-qps   | cfg.QPS               | 20.0          | Set the QPS rate for throttling requests sent to the apiserver |\n| kube-api-burst | cfg.Burst             | 30            | Set the burst for throttling requests sent to the apiserver    |\n"
  },
  {
    "path": "content/docs/2.4/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                               | Type      | Description                                                                                                                 |\n|-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                 | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                    | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`           | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`              | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`               | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                  | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                  | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`        | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                   | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`        | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`      | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded` | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                                   |\n| `ClusterTriggerAuthenticationDeleted`| `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                                     |\n"
  },
  {
    "path": "content/docs/2.4/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n\n## How to get metric when multiple ScaledObjects have the same metric name\n\nKEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown:\n\n```\nError from server: exactly one ScaledObject should match label\n```\n\nIn this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following:\n\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels}\n```\n\nOnce you have the selector, you have to add it to your query string as following:\n\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}\"\n```"
  },
  {
    "path": "content/docs/2.4/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.4/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.4/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed the number of partitions on a topic.\n That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    version: 1.0.0\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag.\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.4/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName\n    dimensionName: QueueName\n    # Required: Dimension Value - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Metric Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)). (Default: `300`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets       # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n\n> For the purposes of scaling, \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing.\n\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `\"\"`)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Required - Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolID` - Id of the queue.\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on of the `blobContainerName`, `blobPrefix` and `blobDelimiter`. For example: **azure-blob-functions-blob-myprefix-example**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.4/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Optional - Default is 5\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. The `subscriptionSize` determines the target average which the deployment will be scaled on. The default `subscriptionSize` is 5.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Password Authentication:**\n\n- `ADMIN_USER` - The admin REST endpoint username for your MQ Queue Manager.\n- `ADMIN_PASSWORD` - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to a masked version of the url and organization name if not set by the user (metrics name value would be then `influxdb-https---xxx-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on masked version of the server url and organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the amount of pods which matches the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`.\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a  metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a  metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a  metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on the values in trigger spec, for example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on masked version of the server hostname and collection name. For example: **mongodb-mongodb---test_user-test_password@xxx-27017-test-test_collection**. If using more than one trigger it is required that all `metricName`(s) be unique. The value will be prefixed with `mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `password` - Password for the configured user to login to MongoDB server.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. The default for MSSQL is 1433.\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the `database` value (if specified), or the `host` value, or will be in the form `mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` MySQL connection string that should point to environment variable with valid value\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment\n variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to MySQL database variables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\n**Connection Authentication:**\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: gonuts\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```"
  },
  {
    "path": "content/docs/2.4/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: 1250 #required\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application.\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n**Password Authentication:**\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n**Application Credentials Authentication:**\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n**Password Authentication:**\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n**Application Credentials Authentication:**\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.4/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a postgresql query\n\nThe Postgresql scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for postgreSQL database.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to postgreSQL database variables.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Metric name to use.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100\" # message backlog or publish/sec. target per instance\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname and password fields need to be set to the names of the environment variables in the target deployment that contain the host name and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n**Password Authentication:**\n\n- `password` - Redis password to authenticate with.\n\n#### Using password authentication\n\nUse the `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-password\ntype: Opaque\ndata:\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: password\n      name: redis-streams-password # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue.\n\nThe scaler creates one browser node per pending request in session queue. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly, for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n"
  },
  {
    "path": "content/docs/2.4/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:        http://solace_broker:8080\n    messageVpn:               message-vpn\n    queueName:                queue_name\n    messageCountTarget:       '100'\n    messageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                 semp-user\n    password:                 semp-pwd\n    usernameFromEnv:          ENV_VAR_USER\n    passwordFromEnv:          ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.4/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.5/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.5/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.5/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.5/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam | gcp  # Optional. Default: none\n  secretTargetRef:                                       # Optional.\n  - parameter: {scaledObject-parameter-name}             # Required.\n    name: {secret-name}                                  # Required.\n    key: {secret-key-name}                               # Required.\n  env:                                                   # Optional.\n  - parameter: {scaledObject-parameter-name}             # Required.\n    name: {env-name}                                     # Required.\n    containerName: {container-name}                      # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                        # Optional.\n    address: {hashicorp-vault-address}                   # Required.\n    namespace: {hashicorp-vault-namespace}               # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                   # Required.\n    role: {hashicorp-vault-role}                         # Optional.\n    mount: {hashicorp-vault-mount}                       # Optional.\n    credential:                                          # Optional.\n      token: {hashicorp-vault-token}                     # Optional.\n      serviceAccount: {path-to-service-account-file}     # Optional.\n    secrets:                                             # Required.\n    - parameter: {scaledObject-parameter-name}           # Required.\n      key: {hashicorp-vault-secret-key-name}              # Required.\n      path: {hashicorp-vault-secret-path}                 # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}"
  },
  {
    "path": "content/docs/2.5/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec).\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.5/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It is **not** supported by the CPU & memory scalers and will assume that fallback is disabled in those cases. This is because it only supports scalers that present their target as an `AverageValue` metric.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.5/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Optional. Default: default. Which Rollout Strategy KEDA will use.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rolloutStrategy: default # Optional. Default: default. Which Rollout Strategy KEDA will use. \n```\n\nThis optional property specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. \\\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.5/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.5/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects,scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.5.0`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.5.0/keda-2.5.0.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.5.0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.5.0 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.5.0`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.5.0/keda-2.5.0.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.5.0.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.5.0 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.5/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.5/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator \n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Metrics Adapter\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.5/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.5/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n"
  },
  {
    "path": "content/docs/2.5/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.5 has been tested on Kubernetes v1.17.0 or above.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable to your desired timeout in milliseconds. For example, on Linux/Mac/Windows WSL2 operating systems, you'd use this command to set to 1 second:\n\n```shell\nexport KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAnd on Windows Powershell, you'd use this command:\n\n```shell\n$env:KEDA_HTTP_DEFAULT_TIMEOUT=1000\n```\n\nAll applicable scalers will use this timeout. Setting a per-scaler timeout is currently unsupported.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag   | Client Config Setting | Default Value | Description                                                    |\n| -------------- | --------------------- | ------------- | -------------------------------------------------------------- |\n| kube-api-qps   | cfg.QPS               | 20.0          | Set the QPS rate for throttling requests sent to the apiserver |\n| kube-api-burst | cfg.Burst             | 30            | Set the burst for throttling requests sent to the apiserver    |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment     | Default Value | Affected reconciler           |\n| ------------------------------------- | -------------- | ------------- | ----------------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator       | 5             | ScaledObjectReconciler        |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator       | 1             | ScaledJobReconciler           |\n| KEDA_METRICS_CTRL_MAX_RECONCILES      | Metrics Server | 1             | MetricsScaledObjectReconciler |\n"
  },
  {
    "path": "content/docs/2.5/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                               | Type      | Description                                                                                                                 |\n|-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                 | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                    | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`           | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`              | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`               | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                  | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                  | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`        | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                   | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`        | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`      | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded` | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                                   |\n| `ClusterTriggerAuthenticationDeleted`| `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                                     |\n"
  },
  {
    "path": "content/docs/2.5/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n\n## How to get metric when multiple ScaledObjects have the same metric name\n\nKEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown:\n\n```\nError from server: exactly one ScaledObject should match label\n```\n\nIn this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following:\n\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels}\n```\n\nOnce you have the selector, you have to add it to your query string as following:\n\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}\"\n```"
  },
  {
    "path": "content/docs/2.5/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.5/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.5/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed the number of partitions on a topic and will not exceed `maxReplicaCount`.\n That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    version: 1.0.0\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag.\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.5/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName\n    dimensionName: QueueName\n    # Required: Dimension Value - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiply of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, that it must be supported by Cloudwatch. More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit is going to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `Average`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: keda-aws-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets       # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets        # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n\n> For the purposes of scaling, \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing.\n\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>\n  AWS_SECRET_ACCESS_KEY: <encoded-key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `\"\"`)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId)\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Required - Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolID` - Id of the queue.\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n- `metricName` - Name to assign to the metric. (Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.5/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n- `parameters` - Parameters that will be used by the search template. It supports multiples param separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password authentication.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  authenticationRef: gcp-pubsub-credentials # Required\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5\" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge\n    subscriptionName: \"mysubscription\" # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\n`authenticationRef` defines how KEDA connect to Google Cloud Platform, to collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n\n- Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n- Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nYou can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`.\nThe mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`.\nThe `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can configure authorization for a `ScaledObject` either directly using credentials in `credentialsFromEnv` or using an `authenticationRef` referencing a `TriggerAuthentication` CRD which configures authorization.\n\n**Pod identity based authentication:**\n- `podIdentity.provider` - Needs to be set to `gcp` on the `TriggerAuthentication` and the pod's [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) or node's (default) service account must be configured correctly.\n\n**Credential based authentication via TriggerAuthentication:**\n- `secretTargetRef` - Needs to be set on the `TriggerAuthentication`, with `parameter=GoogleApplicationCredentials` and `name` must reference a Secret in which `key` is the key containing the JSON ServiceAccount value.\n\n**Credential based authentication via ScaledObject:**\n- `credentialsFromEnv` - Needs to be set on the `ScaledObject`.\n\n### Examples\nTo use the GCP default authentication, you need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: gcp-pubsub-credentials\nspec:\n  podIdentity:\n    provider: gcp # Required\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionName: \"input\" # Required\n    authenticationRef:\n      name: gcp-pubsub-credentials\n```\n\nAlternatively, you can configure the credentials in a secret, via the `TriggerAuthentication`:\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: pubsub-secret\ndata:\n  GOOGLE_APPLICATION_CREDENTIALS_JSON: <json-credential-value>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: gcp-pubsub-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret  # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionName: \"input\" # Required\n    authenticationRef:\n      name: gcp-pubsub-credentials # Required\n```\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '100'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the amount of pods which matches the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`.\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.5/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: 1250 #required\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application.\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.5/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100\" # message backlog or publish/sec. target per instance\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue.\n\nThe scaler creates one browser node per pending request in session queue. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly, for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n"
  },
  {
    "path": "content/docs/2.5/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\naliases = [\"solace\"]\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:        http://solace_broker:8080\n    messageVpn:               message-vpn\n    queueName:                queue_name\n    messageCountTarget:       '100'\n    messageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                 semp-user\n    password:                 semp-pwd\n    usernameFromEnv:          ENV_VAR_USER\n    passwordFromEnv:          ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.5/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.6/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.6/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.6/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.6/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam | gcp  # Optional. Default: none\n  secretTargetRef:                                       # Optional.\n  - parameter: {scaledObject-parameter-name}             # Required.\n    name: {secret-name}                                  # Required.\n    key: {secret-key-name}                               # Required.\n  env:                                                   # Optional.\n  - parameter: {scaledObject-parameter-name}             # Required.\n    name: {env-name}                                     # Required.\n    containerName: {container-name}                      # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                        # Optional.\n    address: {hashicorp-vault-address}                   # Required.\n    namespace: {hashicorp-vault-namespace}               # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                   # Required.\n    role: {hashicorp-vault-role}                         # Optional.\n    mount: {hashicorp-vault-mount}                       # Optional.\n    credential:                                          # Optional.\n      token: {hashicorp-vault-token}                     # Optional.\n      serviceAccount: {path-to-service-account-file}     # Optional.\n    secrets:                                             # Required.\n    - parameter: {scaledObject-parameter-name}           # Required.\n      key: {hashicorp-vault-secret-key-name}              # Required.\n      path: {hashicorp-vault-secret-path}                 # Required.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.6/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec).\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA uses the metric target type `AverageValue` for external metrics. This will cause the metric value returned by the external scaler to be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.6/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It is **not** supported by the CPU & memory scalers and will assume that fallback is disabled in those cases. This is because it only supports scalers that present their target as an `AverageValue` metric.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.6/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Optional. Default: default. Which Rollout Strategy KEDA will use.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rolloutStrategy: default # Optional. Default: default. Which Rollout Strategy KEDA will use. \n```\n\nThis optional property specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. \\\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.6/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.6/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects,scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.6.1`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.6.1/keda-2.6.1.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.6.1.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.6.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.6.1`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.6.1/keda-2.6.1.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.6.1.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.6.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.6/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.6/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator \n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Metrics Adapter\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.6/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.6/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n"
  },
  {
    "path": "content/docs/2.6/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.6 has been tested on Kubernetes v1.17.0 through v1.25.0.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag   | Client Config Setting | Default Value | Description                                                    |\n| -------------- | --------------------- | ------------- | -------------------------------------------------------------- |\n| kube-api-qps   | cfg.QPS               | 20.0          | Set the QPS rate for throttling requests sent to the apiserver |\n| kube-api-burst | cfg.Burst             | 30            | Set the burst for throttling requests sent to the apiserver    |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment     | Default Value | Affected reconciler           |\n| ------------------------------------- | -------------- | ------------- | ----------------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator       | 5             | ScaledObjectReconciler        |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator       | 1             | ScaledJobReconciler           |\n| KEDA_METRICS_CTRL_MAX_RECONCILES      | Metrics Server | 1             | MetricsScaledObjectReconciler |\n\n## Certificates used by KEDA Metrics Server\n\nBy default, KEDA Metrics Server uses self-signed certificates while communicating with Kubernetes API Server. It is recommended to provide own (trusted) certificates instead.\n\nCertificates and CA bundle can be referenced in `args` section in KEDA Metrics Server Deployment:\n\n```yaml\n---\nargs:\n  - \"--client-ca-file=/cabundle/service-ca.crt\"\n  - \"--tls-cert-file=/certs/tls.crt\"\n  - \"--tls-private-key-file=/certs/tls.key\"\n```\n\nThe custom CA bundle should be also referenced in the `v1beta1.external.metrics.k8s.io` [APIService](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA).\n\nYou should also make sure that `insecureSkipTLSVerify` is not set to `true`.\n\n```yaml\n---\nspec:\n  service:\n    namespace: keda\n    name: keda-metrics-apiserver\n    port: 443\n  group: external.metrics.k8s.io\n  version: v1beta1\n  caBundle: >-\n    YOURCABUNDLE...\n  groupPriorityMinimum: 100\n  versionPriority: 100\n```\n"
  },
  {
    "path": "content/docs/2.6/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                               | Type      | Description                                                                                                                 |\n|-------------------------------------|-----------|-----------------------------------------------------------------------------------------------------------------------------|\n| `ScaledObjectReady`                 | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                    | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`           | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`              | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`               | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                  | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                  | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`        | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed` | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                   | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`        | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`      | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded` | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                                   |\n| `ClusterTriggerAuthenticationDeleted`| `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                                     |\n"
  },
  {
    "path": "content/docs/2.6/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n\n## How to get metric when multiple ScaledObjects have the same metric name\n\nKEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown:\n\n```\nError from server: exactly one ScaledObject should match label\n```\n\nIn this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following:\n\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels}\n```\n\nOnce you have the selector, you have to add it to your query string as following:\n\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}\"\n```"
  },
  {
    "path": "content/docs/2.6/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.6/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.6/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    version: 1.0.0\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.6/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Required: Dimension Name - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName\n    dimensionName: QueueName\n    # Required: Dimension Value - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2\n    dimensionValue: keda\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiply of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, that it must be supported by Cloudwatch. More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit is going to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `Average`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n\n> For the purposes of scaling, \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing.\n\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure Active Directory pod-managed identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) can be used\nin place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (default: `\"\"`)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId)\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n- `metricName` - Name to assign to the metric. (Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.6/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7\"\n    type: \"global\"\n    age: \"120\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling.\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: (Global or Average). Whether the target value is global or average per pod. Default: Average\n      type: \"Global\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n"
  },
  {
    "path": "content/docs/2.6/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password authentication.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform Pub/Sub.\"\ngo_file = \"gcp_pub_sub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  authenticationRef: gcp-pubsub-credentials # Required\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5\" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge\n    subscriptionName: \"mysubscription\" # Required\n```\n\nThe Google Cloud Platform (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\n`authenticationRef` defines how KEDA connect to Google Cloud Platform, to collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n\n- Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n- Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nYou can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`.\nThe mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`.\nThe `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can configure authorization for a `ScaledObject` either directly using credentials in `credentialsFromEnv` or using an `authenticationRef` referencing a `TriggerAuthentication` CRD which configures authorization.\n\n**Pod identity based authentication:**\n- `podIdentity.provider` - Needs to be set to `gcp` on the `TriggerAuthentication` and the pod's [Workload Identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) or node's (default) service account must be configured correctly.\n\n**Credential based authentication via TriggerAuthentication:**\n- `secretTargetRef` - Needs to be set on the `TriggerAuthentication`, with `parameter=GoogleApplicationCredentials` and `name` must reference a Secret in which `key` is the key containing the JSON ServiceAccount value.\n\n**Credential based authentication via ScaledObject:**\n- `credentialsFromEnv` - Needs to be set on the `ScaledObject`.\n\n### Examples\nTo use the GCP default authentication, you need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: gcp-pubsub-credentials\nspec:\n  podIdentity:\n    provider: gcp # Required\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionName: \"input\" # Required\n    authenticationRef:\n      name: gcp-pubsub-credentials\n```\n\nAlternatively, you can configure the credentials in a secret, via the `TriggerAuthentication`:\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: pubsub-secret\ndata:\n  GOOGLE_APPLICATION_CREDENTIALS_JSON: <json-credential-value>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: gcp-pubsub-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret  # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionName: \"input\" # Required\n    authenticationRef:\n      name: gcp-pubsub-credentials # Required\n```\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      subscriptionSize: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '100'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`.\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metadata:\n    # Required\n    type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metadata:\n      type: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetAverageValue` in the Horizontal Pod Autoscaler (HPA).\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetAverageValue` in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.6/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: '100'\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetAverageValue` in the HPA configuration.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        account: '1234567'\n        region: \"US\"\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: 1250 #required\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application.\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.6/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetAverageValue` in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100\" # message backlog or publish/sec. target per instance\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue.\n\nThe scaler creates one browser node per pending request in session queue. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly, for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n"
  },
  {
    "path": "content/docs/2.6/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\naliases = [\"solace\"]\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:        http://solace_broker:8080\n    messageVpn:               message-vpn\n    queueName:                queue_name\n    messageCountTarget:       '100'\n    messageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                 semp-user\n    password:                 semp-pwd\n    usernameFromEnv:          ENV_VAR_USER\n    passwordFromEnv:          ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.6/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.7/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently pod identity providers are not supported for key vault.\n\nYou need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Required.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.7/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.7/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.7/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | aws-eks | aws-kiam | gcp  # Optional. Default: none\n  secretTargetRef:                                       # Optional.\n  - parameter: {scaledObject-parameter-name}             # Required.\n    name: {secret-name}                                  # Required.\n    key: {secret-key-name}                               # Required.\n  env:                                                   # Optional.\n  - parameter: {scaledObject-parameter-name}             # Required.\n    name: {env-name}                                     # Required.\n    containerName: {container-name}                      # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                        # Optional.\n    address: {hashicorp-vault-address}                   # Required.\n    namespace: {hashicorp-vault-namespace}               # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                   # Required.\n    role: {hashicorp-vault-role}                         # Optional.\n    mount: {hashicorp-vault-mount}                       # Optional.\n    credential:                                          # Optional.\n      token: {hashicorp-vault-token}                     # Optional.\n      serviceAccount: {path-to-service-account-file}     # Optional.\n    secrets:                                             # Required.\n    - parameter: {scaledObject-parameter-name}           # Required.\n      key: {hashicorp-vault-secret-key-name}              # Required.\n      path: {hashicorp-vault-secret-path}                 # Required.\n  azureKeyVault:                                         # Optional.\n    vaultUri: {key-vault-address}                        # Required.\n    credentials:                                         # Required.\n      clientId: {azure-ad-client-id}                     # Required.\n      clientSecret:                                      # Required.\n        valueFrom:                                       # Required.\n          secretKeyRef:                                  # Required.\n            name: {k8s-secret-with-azure-ad-secret}      # Required.\n            key: {key-within-the-secret}                 # Required.\n      tenantId: {azure-ad-tenant-id}                     # Required.\n    cloud:                                               # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}         # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}  # Required when type = Private.\n    secrets:                                             # Required.\n    - parameter: {param-name-used-for-auth}              # Required.\n      name: {key-vault-secret-name}                      # Required.\n      version: {key-vault-secret-version}                # Optional.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.7/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec).\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.7/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n```\n\nThe presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.7/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives on the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Optional. Default: default. Which Rollout Strategy KEDA will use.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rolloutStrategy: default # Optional. Default: default. Which Rollout Strategy KEDA will use. \n```\n\nThis optional property specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. \\\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.7/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.7/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects,scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.7.1`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.7.1/keda-2.7.1.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.7.1.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.7.1 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.7.1`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.7.1/keda-2.7.1.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.7.1.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.7.1 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.7/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.7/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator \n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Metrics Adapter\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`.  The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.7/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.7/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n"
  },
  {
    "path": "content/docs/2.7/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.7 has been tested on Kubernetes v1.17.0 through v1.25.0.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag   | Client Config Setting | Default Value | Description                                                    |\n| -------------- | --------------------- | ------------- | -------------------------------------------------------------- |\n| kube-api-qps   | cfg.QPS               | 20.0          | Set the QPS rate for throttling requests sent to the apiserver |\n| kube-api-burst | cfg.Burst             | 30            | Set the burst for throttling requests sent to the apiserver    |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment     | Default Value | Affected reconciler           |\n| ------------------------------------- | -------------- | ------------- | ----------------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator       | 5             | ScaledObjectReconciler        |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator       | 1             | ScaledJobReconciler           |\n| KEDA_METRICS_CTRL_MAX_RECONCILES      | Metrics Server | 1             | MetricsScaledObjectReconciler |\n\n## Certificates used by KEDA Metrics Server\n\nBy default, KEDA Metrics Server uses self-signed certificates while communicating with Kubernetes API Server. It is recommended to provide own (trusted) certificates instead.\n\nCertificates and CA bundle can be referenced in `args` section in KEDA Metrics Server Deployment:\n\n```yaml\n---\nargs:\n  - \"--client-ca-file=/cabundle/service-ca.crt\"\n  - \"--tls-cert-file=/certs/tls.crt\"\n  - \"--tls-private-key-file=/certs/tls.key\"\n```\n\nThe custom CA bundle should be also referenced in the `v1beta1.external.metrics.k8s.io` [APIService](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA).\n\nYou should also make sure that `insecureSkipTLSVerify` is not set to `true`.\n\n```yaml\n---\nspec:\n  service:\n    namespace: keda\n    name: keda-metrics-apiserver\n    port: 443\n  group: external.metrics.k8s.io\n  version: v1beta1\n  caBundle: >-\n    YOURCABUNDLE...\n  groupPriorityMinimum: 100\n  versionPriority: 100\n```\n"
  },
  {
    "path": "content/docs/2.7/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.7/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n\n## How to get metric when multiple ScaledObjects have the same metric name\n\nKEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown:\n\n```\nError from server: exactly one ScaledObject should match label\n```\n\nIn this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following:\n\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels}\n```\n\nOnce you have the selector, you have to add it to your query string as following:\n\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}\"\n```\n"
  },
  {
    "path": "content/docs/2.7/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.7/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.7/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    version: 1.0.0\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert` and `key`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.7/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2\"\n    minMetricValue: \"0\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions on the CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiply of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric is going to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency is going to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, that it must be supported by Cloudwatch. More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit is going to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `Average`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Required: tableName\n    tableName: myTableName\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `tableName` - The target table where the scaler execute the query.\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```"
  },
  {
    "path": "content/docs/2.7/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n\n> For the purposes of scaling, \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing.\n\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure Active Directory pod-managed identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) can be used\nin place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"1000\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    clientSecret: t0p-s3cret  # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `clientSecret` - Password of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure Active Directory pod-managed identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target.\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"1\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions.\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `metricName` - Name to assign to the metric. (Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; Allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.7/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    metricUnavailableValue: \"0\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling.\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n"
  },
  {
    "path": "content/docs/2.7/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password authentication.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5\" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n`subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n\n- Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n- Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nYou can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`.\nThe mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`.\nThe `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```"
  },
  {
    "path": "content/docs/2.7/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```"
  },
  {
    "path": "content/docs/2.7/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```"
  },
  {
    "path": "content/docs/2.7/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '100'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"100\"\n    minMetricValue: \"1\"\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric.\n- `minMetricValue` - Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active.\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query.\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`.\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0.\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA.\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.7/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: '100'\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration.\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: 1250 #required\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application.\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.7/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: 1\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for.\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # Optional. X-Scope-OrgID header for Cortex.\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for.\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - The `X-Scope-OrgID` header to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100\" # message backlog or publish/sec. target per instance\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on.\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly, for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n"
  },
  {
    "path": "content/docs/2.7/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:        http://solace_broker:8080\n    messageVpn:               message-vpn\n    queueName:                queue_name\n    messageCountTarget:       '100'\n    messageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                 semp-user\n    password:                 semp-pwd\n    usernameFromEnv:          ENV_VAR_USER\n    passwordFromEnv:          ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.7/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.8/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently pod identity providers are not supported for key vault.\n\nYou need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Required.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.8/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.8/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.8/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Available authentication providers for KEDA\n\nAuthentication parameters can be retrieved from a variety of authentication providers in KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.8/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\ntype Scaler interface {\n\tGetMetrics(ctx context.Context, metricName string, metricSelector labels.Selector) ([]external_metrics.ExternalMetricValue, error)\n\tGetMetricSpecForScaling() []v2beta2.MetricSpec\n\tIsActive(ctx context.Context) (bool, error)\n\tClose() error\n}\n\ntype PushScaler interface {\n\tScaler\n\n\tRun(ctx context.Context, active chan<- bool)\n}\n```\n\nThe `Scaler` interface defines 4 methods:\n\n- `IsActive` is called on `pollingInterval`. When `isActive` returns `true`, KEDA will scale to what is returned by `GetMetricSpec` limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/2.6/concepts/scaling-deployments/#scaledobject-spec).\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpec` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetrics` returns the value of the metric referred to from `GetMetricSpec`. For more details refer to [Implementing `GetMetrics`](#6-implementing-getmetrics).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetrics` and `GetMetricsSpec` mirror their counterparts in the `Scaler` interface for creating HPA definition.\n- `IsActive` maps to the `IsActive` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.8/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and set up an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default, it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n```\n\nThe presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition.\n\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.8/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.8/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.8/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.16 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.8.2`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.8.2/keda-2.8.2.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2..0.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.8.2 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.8.2`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.8.2/keda-2.8.2.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.8.2.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.8.2 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.8/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.8/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Metrics Adapter\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n"
  },
  {
    "path": "content/docs/2.8/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.8/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n"
  },
  {
    "path": "content/docs/2.8/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA v2.8 has been tested on Kubernetes v1.17.0 through v1.25.0.\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag   | Client Config Setting | Default Value | Description                                                    |\n| -------------- | --------------------- | ------------- | -------------------------------------------------------------- |\n| kube-api-qps   | cfg.QPS               | 20.0          | Set the QPS rate for throttling requests sent to the apiserver |\n| kube-api-burst | cfg.Burst             | 30            | Set the burst for throttling requests sent to the apiserver    |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment     | Default Value | Affected reconciler           |\n| ------------------------------------- | -------------- | ------------- | ----------------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator       | 5             | ScaledObjectReconciler        |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator       | 1             | ScaledJobReconciler           |\n| KEDA_METRICS_CTRL_MAX_RECONCILES      | Metrics Server | 1             | MetricsScaledObjectReconciler |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Certificates used by KEDA Metrics Server\n\nBy default, KEDA Metrics Server uses self-signed certificates while communicating with Kubernetes API Server. It is recommended to provide own (trusted) certificates instead.\n\nCertificates and CA bundle can be referenced in `args` section in KEDA Metrics Server Deployment:\n\n```yaml\n---\nargs:\n  - \"--client-ca-file=/cabundle/service-ca.crt\"\n  - \"--tls-cert-file=/certs/tls.crt\"\n  - \"--tls-private-key-file=/certs/tls.key\"\n```\n\nThe custom CA bundle should be also referenced in the `v1beta1.external.metrics.k8s.io` [APIService](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA).\n\nYou should also make sure that `insecureSkipTLSVerify` is not set to `true`.\n\n```yaml\n---\nspec:\n  service:\n    namespace: keda\n    name: keda-metrics-apiserver\n    port: 443\n  group: external.metrics.k8s.io\n  version: v1beta1\n  caBundle: >-\n    YOURCABUNDLE...\n  groupPriorityMinimum: 100\n  versionPriority: 100\n```\n"
  },
  {
    "path": "content/docs/2.8/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.8/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n\n## How to get metric when multiple ScaledObjects have the same metric name\n\nKEDA will try to select the proper `ScaledObject` for your metric and there should only be one. In case of having multiple `ScaledObject`s in the same namespace with the same metric name, an error like this will be thrown:\n\n```\nError from server: exactly one ScaledObject should match label\n```\n\nIn this case, you should add in the query string the `labelSelector` to match the proper `ScaledObject` (in url format). The needed selector is `scaledobject.keda.sh/name: {ScaledObjectName}`. You can achieve this as following:\n\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.metadata.labels}\n```\n\nOnce you have the selector, you have to add it to your query string as following:\n\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3D{ScaledObjectName}\"\n```"
  },
  {
    "path": "content/docs/2.8/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.8/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.8/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    version: 1.0.0\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256` or `scram_sha512`, `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.8/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Required: tableName\n    tableName: myTableName\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `tableName` - The target table where the scaler execute the query.\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```"
  },
  {
    "path": "content/docs/2.8/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`.\n\n- `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well.\n  - When set to `false` \"actual messages\" is equal to `ApproximateNumberOfMessages`. When set to `true` \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```"
  },
  {
    "path": "content/docs/2.8/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    clientSecret: t0p-s3cret  # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `clientSecret` - Password of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage.\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing, for example Dapr.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored)\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n###Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n      metricName: \"test_keyspace\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `metricName` - Name to assign to the metric. (Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.8/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n"
  },
  {
    "path": "content/docs/2.8/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password authentication.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5\" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge\n    activationValue: \"10\" # Optional - Default is 0\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n`subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n\n- Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n- Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nYou can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`.\nThe mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`.\nThe `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```"
  },
  {
    "path": "content/docs/2.8/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100'\n    activationTargetValue: \"10\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```"
  },
  {
    "path": "content/docs/2.8/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```"
  },
  {
    "path": "content/docs/2.8/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`.  (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.8/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # Optional. X-Scope-OrgID header for Cortex.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - The `X-Scope-OrgID` header to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Authentication Parameters\n\n  If TLS is required you should set `tls` to `enable`. If required for your Pulsar configuration, you may also provide a `ca`, `cert` and `key`. `ca`, `cert` and `key` must be specified together.\n\n\n**TLS:**\n\n- `tls`: Optional. To enable SSL auth for Pulsar, set this to `enable`. If not set, TLS for Pulsar is not used, Your shoule set this key to trigger metadata.\n- `ca`: Certificate authority file for TLS client authentication. \n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n### Example\n\nYour pulsar cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\nYour pulsar cluster turn on TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      tls: \"enable\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\n> ⚠️ **WARNING:** In this version, `enableTLS: true` automatically skips the certificate verification which is insecure. Use v2.9 or above to properly verify the server certificate.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n"
  },
  {
    "path": "content/docs/2.8/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    activationMessageCountTarget:       '100'\n    activationMessageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.8/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/2.9/_index.md",
    "content": "+++\ntitle = \"The KEDA Documentation\"\nweight = 1\n+++\n\nWelcome to the documentation for **KEDA**, the Kubernetes Event-driven Autoscaler. Use the navigation to the left to learn more about how to use KEDA and its components.  \n\nAdditions and contributions to these docs are managed on [the keda-docs GitHub repo](https://github.com/kedacore/keda-docs).\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/_index.md",
    "content": "+++\ntitle = \"Authentication Providers\"\nweight = 5\n+++\n\nAvailable authentication providers for KEDA:\n\n{{< authentication-providers >}}\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/aws-eks.md",
    "content": "+++\ntitle = \"AWS EKS Pod Identity Webhook\"\n+++\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/aws-kiam.md",
    "content": "+++\ntitle = \"AWS Kiam Pod Identity\"\n+++\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/azure-ad-pod-identity.md",
    "content": "+++\ntitle = \"Azure AD Pod Identity\"\n+++\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/azure-ad-workload-identity.md",
    "content": "+++\ntitle = \"Azure AD Workload Identity\"\n+++\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n## Considerations about Federations and Overrides\n\nThe concept of \"overrides\" can be somewhat confusing in certain scenarios, as it may not always be clear which service account needs to be federated with a specific Azure identity to ensure proper functionality.\n\nLet's clarify this with two examples:\n\n### Case 1\n\nImagine you have an identity for KEDA that has access to ServiceBus A, ServiceBus B, and ServiceBus C. Additionally, you have separate identities for various workloads, resulting in the following setup:\n\n- KEDA's identity with access to ServiceBus A, ServiceBus B, and ServiceBus C (the identity set during installation and not overridden).\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, KEDA's Managed Service Identity should only be federated with KEDA's service account.\n\n### Case 2\n\nTo avoid granting too many permissions to KEDA's identity, you have a KEDA identity without access to any Service Bus (perhaps unrelated, such as Key Vault). Similar to the previous scenario, you also have separate identities for your workloads:\n\n- KEDA's identity without access to any Service Bus.\n- Workload A's identity with access to Service Bus A.\n- Workload B's identity with access to Service Bus B.\n- Workload C's identity with access to Service Bus C.\n\nIn this case, you are overriding the default identity set during installation through the \"TriggerAuthentication\" option (`.spec.podIdentity.identityId`). Each \"ScaledObject\" now uses its own \"TriggerAuthentication,\" with each specifying an override (Workload A's TriggerAuthentication sets the identityId for Workload A, Workload B's for Workload B, and so on). Consequently, you don't need to stack excessive permissions on KEDA's identity. However, in this scenario, KEDA's service account must be federated with all the identities it may attempt to assume:\n\n- TriggerAuthentications without overrides will use KEDA's identity (for tasks such as accessing the Key Vault).\n- TriggerAuthentications with overrides will use the identity specified in the TriggerAuthentication (requiring KEDA's service account to be federated with them).\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/azure-key-vault.md",
    "content": "+++\ntitle = \"Azure Key Vault secret\"\n+++\n\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nCurrently, `azure` and `azure-workload` pod identity providers are supported for Azure Key Vault using `podIdentity` inside `azureKeyVault`.\n\nService principal authentication is also supported, needing to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specifying its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  podIdentity:                                          # Optional.\n    provider: azure | azure-workload                    # Required.\n    identityId: <identity-id>                           # Optional\n  credentials:                                          # Optional.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/environment-variable.md",
    "content": "+++\ntitle = \"Environment variable\"\n+++\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/gcp-workload-identity.md",
    "content": "+++\ntitle = \"GCP Workload Identity\"\n+++\n\n[**GCP Workload Identity**](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity) allows workloads in your GKE clusters to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.\n\nYou can tell KEDA to use GCP Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: gcp # Optional. Default: none\n```\n### Steps to setup Workload Identity\nIf you are using podIdentity provider as `gcp`, you need to setup workload identity as below and your GKE cluster must have Workload Identity enabled.\n\n* You need to create a GCP IAM service account with proper permissions to retrieve metrics for particular scalers.\n\n  ```shell\n  gcloud iam service-accounts create GSA_NAME \\\n  --project=GSA_PROJECT\n  ```\n    \n  Replace the following: \\\n  GSA_NAME: the name of the new IAM service account.\\\n  GSA_PROJECT: the project ID of the Google Cloud project for your IAM service account.\n\n\n* Ensure that your IAM service account has the [roles](https://cloud.google.com/iam/docs/understanding-roles) you need. You can grant additional roles using the following command:\n\n  ```shell\n  gcloud projects add-iam-policy-binding PROJECT_ID \\\n  --member \"serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\" \\\n  --role \"ROLE_NAME\"\n  ```\n\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  ROLE_NAME: the IAM role to assign to your service account, like roles/monitoring.viewer.\n\n* Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts. This binding allows the Kubernetes service account to act as the IAM service account.\n  ```shell\n  gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \\\n      --role roles/iam.workloadIdentityUser \\\n      --member \"serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\"\n  ```\n  Replace the following:\n\n  PROJECT_ID: your Google Cloud project ID. \\\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \\\n  NAMESPACE: Namespace where keda operator is installed; defaults to `keda` . \\\n  KSA_NAME: Kubernetes service account name of the keda; defaults to `keda-operator` .\n* Then you need to annotate the Kubernetes service account with the email address of the IAM service account.\n\n  ```shell\n  kubectl annotate serviceaccount keda-operator \\\n    --namespace keda \\\n    iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com\n  ```\n  Replace the following: \\\n\n  GSA_NAME: the name of your IAM service account. \\\n  GSA_PROJECT: the project ID of the Google Cloud project of your IAM service account. \n\n\n  Refer to GCP official [documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to) for more. \n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/hashicorp-vault.md",
    "content": "+++\ntitle = \"Hashicorp Vault secret\"\n+++\n\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n"
  },
  {
    "path": "content/docs/2.9/authentication-providers/secret.md",
    "content": "+++\ntitle = \"Secret\"\n+++\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n"
  },
  {
    "path": "content/docs/2.9/concepts/_index.md",
    "content": "+++\ntitle = \"KEDA Concepts\"\ndescription = \"What KEDA is and how it works\"\nweight = 1\n+++\n\n## What is KEDA?\n\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler.  With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster.  KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication.  With KEDA you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function.  This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\n## How KEDA works\n\nKEDA performs two key roles within Kubernetes:\n\n1. **Agent** — KEDA activates and deactivates Kubernetes [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment) to scale to and from zero on no events. This is one of the primary roles of the `keda-operator` container that runs when you install KEDA.\n1. **Metrics** — KEDA acts as a [Kubernetes metrics server](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics) that exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler to drive scale out.  It is up to the Deployment to consume the events directly from the source.  This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.  The metric serving is the primary role of the `keda-operator-metrics-apiserver` container that runs when you install KEDA.\n\n## Architecture\n\nThe diagram below shows how KEDA works in conjunction with the Kubernetes Horizontal Pod Autoscaler, external event sources, and Kubernetes' [etcd](https://etcd.io) data store:\n\n![KEDA architecture](/img/keda-arch-no-webhooks.png)\n\n### Event sources and scalers\n\nKEDA has a wide range of [**scalers**](/scalers) that can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source. The following scalers are available:\n\n{{< scalers-compact >}}\n\n### Custom Resources (CRD)\n\nWhen you install KEDA, it creates four custom resources:\n\n1. `scaledobjects.keda.sh`\n1. `scaledjobs.keda.sh`\n1. `triggerauthentications.keda.sh`\n1. `clustertriggerauthentications.keda.sh`\n\nThese custom resources enable you to map an event source (and the authentication to that event source) to a Deployment, StatefulSet, Custom Resource or Job for scaling.\n- `ScaledObjects` represent the desired mapping between an event source (e.g. Rabbit MQ) and the Kubernetes Deployment, StatefulSet or any Custom Resource that defines `/scale` subresource.\n- `ScaledJobs` represent the mapping between event source and Kubernetes Job.\n- `ScaledObject`/`ScaledJob` may also reference a `TriggerAuthentication` or `ClusterTriggerAuthentication` which contains the authentication configuration or secrets to monitor the event source.\n\n## Deploy KEDA\n\nSee the [Deployment](../deploy) documentation for instructions on how to deploy KEDA into any cluster using tools like [Helm](../deploy/#helm).\n"
  },
  {
    "path": "content/docs/2.9/concepts/authentication.md",
    "content": "+++\ntitle = \"Authentication\"\nweight = 500\n+++\n\nOften a scaler will require authentication or secrets and config to check for events.\n\nKEDA provides a few secure patterns to manage authentication flows:\n\n* Configure authentication per `ScaledObject`\n* Re-use per-namespace credentials or delegate authentication with `TriggerAuthentication`\n* Re-use global credentials with `ClusterTriggerAuthentication`\n\n## Defining secrets and config maps on ScaledObject\n\nSome metadata parameters will not allow resolving from a literal value, and will instead require a reference to a secret, config map, or environment variable defined on the target container.\n\n> 💡 ***TIP:*** *If creating a deployment yaml that references a secret, be sure the secret is created before the deployment that references it, and the scaledObject after both of them to avoid invalid references.*\n\n### Example\n\nIf using the [RabbitMQ scaler](https://keda.sh/docs/2.1/scalers/rabbitmq-queue/), the `host` parameter may include passwords so is required to be a reference.  You can create a secret with the value of the `host` string, reference that secret in the deployment, and map it to the `ScaledObject` metadata parameter like below:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: {secret-name}\ndata:\n  {secret-key-name}: YW1xcDovL3VzZXI6UEFTU1dPUkRAcmFiYml0bXEuZGVmYXVsdC5zdmMuY2x1c3Rlci5sb2NhbDo1Njcy #base64 encoded per secret spec\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: {deployment-name}\n  namespace: default\n  labels:\n    app: {deployment-name}\nspec:\n  selector:\n    matchLabels:\n      app: {deployment-name}\n  template:\n    metadata:\n      labels:\n        app: {deployment-name}\n    spec:\n      containers:\n      - name: {deployment-name}\n        image: {container-image}\n        envFrom:\n        - secretRef:\n            name: {secret-name}\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: {deployment-name}\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: {secret-key-name}\n      queueLength  : '5'\n```\n\nIf you have multiple containers in a deployment, you will need to include the name of the container that has the references in the `ScaledObject`.  If you do not include a `envSourceContainerName` it will default to the first container.  KEDA will attempt to resolve references from secrets, config maps, and environment variables of the container.\n\n### The downsides\n\nWhile this method works for many scenarios, there are some downsides:\n\n* **Difficult to efficiently share auth** config across `ScaledObjects`\n* **No support for referencing a secret directly**, only secrets that are referenced by the container\n* **No support for other types of authentication flows** such as *pod identity* where access to a source could be acquired with no secrets or connection strings\n\nFor these and other reasons, we also provide a `TriggerAuthentication` resource to define authentication as a separate resource to a `ScaledObject`. This allows you to reference secrets directly, configure to use pod identity or use authentication object managed by a different team.\n\n## Re-use credentials and delegate auth with TriggerAuthentication\n\n`TriggerAuthentication` allows you to describe authentication parameters separate from the `ScaledObject` and the deployment containers.  It also enables more advanced methods of authentication like \"pod identity\", authentication re-use or allowing IT to configure the authentication.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: {trigger-authentication-name}\n  namespace: default # must be same namespace as the ScaledObject\nspec:\n  podIdentity:\n      provider: none | azure | azure-workload | aws-eks | aws-kiam | gcp  # Optional. Default: none\n      identityId: <identity-id>                                           # Optional. Only used by azure & azure-workload providers.\n  secretTargetRef:                                                        # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {secret-name}                                                   # Required.\n    key: {secret-key-name}                                                # Required.\n  env:                                                                    # Optional.\n  - parameter: {scaledObject-parameter-name}                              # Required.\n    name: {env-name}                                                      # Required.\n    containerName: {container-name}                                       # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n  hashiCorpVault:                                                         # Optional.\n    address: {hashicorp-vault-address}                                    # Required.\n    namespace: {hashicorp-vault-namespace}                                # Optional. Default is root namespace. Useful for Vault Enterprise\n    authentication: token | kubernetes                                    # Required.\n    role: {hashicorp-vault-role}                                          # Optional.\n    mount: {hashicorp-vault-mount}                                        # Optional.\n    credential:                                                           # Optional.\n      token: {hashicorp-vault-token}                                      # Optional.\n      serviceAccount: {path-to-service-account-file}                      # Optional.\n    secrets:                                                              # Required.\n    - parameter: {scaledObject-parameter-name}                            # Required.\n      key: {hashicorp-vault-secret-key-name}                               # Required.\n      path: {hashicorp-vault-secret-path}                                  # Required.\n  azureKeyVault:                                                          # Optional.\n    vaultUri: {key-vault-address}                                         # Required.\n    podIdentity:                                                          # Optional. Required when using pod identity.\n      provider: azure | azure-workload                                    # Required.\n      identityId: <identity-id>                                           # Optional\n    credentials:                                                          # Optional. Required when not using pod identity.\n      clientId: {azure-ad-client-id}                                      # Required.\n      clientSecret:                                                       # Required.\n        valueFrom:                                                        # Required.\n          secretKeyRef:                                                   # Required.\n            name: {k8s-secret-with-azure-ad-secret}                       # Required.\n            key: {key-within-the-secret}                                  # Required.\n      tenantId: {azure-ad-tenant-id}                                      # Required.\n    cloud:                                                                # Optional.\n      type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n      keyVaultResourceURL: {key-vault-resource-url-for-cloud}             # Required when type = Private.\n      activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}      # Required when type = Private.\n    secrets:                                                              # Required.\n    - parameter: {param-name-used-for-auth}                               # Required.\n      name: {key-vault-secret-name}                                       # Required.\n      version: {key-vault-secret-version}                                 # Optional.\n```\n\nBased on the requirements you can mix and match the reference types providers in order to configure all required parameters.\n\nEvery parameter you define in `TriggerAuthentication` definition does not need to be included in the `metadata` of the trigger for your `ScaledObject` definition. To reference a `TriggerAuthentication` from a `ScaledObject` you add the `authenticationRef` to the trigger.\n\n```yaml\n# some Scaled Object\n# ...\n  triggers:\n  - type: {scaler-type}\n    metadata:\n      param1: {some-value}\n    authenticationRef:\n      name: {trigger-authentication-name} # this may define other params not defined in metadata\n```\n\n## Authentication scopes: Namespace vs. Cluster\n\nEach `TriggerAuthentication` is defined in one namespace and can only be used by a `ScaledObject` in that same namespace. For cases where you want to share a single set of credentials between scalers in many namespaces, you can instead create a `ClusterTriggerAuthentication`. As a global object, this can be used from any namespace. To set a trigger to use a `ClusterTriggerAuthentication`, add a `kind` field to the authentication reference:\n\n```yaml\n    authenticationRef:\n      name: {cluster-trigger-authentication-name}\n      kind: ClusterTriggerAuthentication\n```\n\nBy default, Secrets loaded from a `secretTargetRef` must be in the same namespace as KEDA is deployed in (usually `keda`). This can be overridden by setting a `KEDA_CLUSTER_OBJECT_NAMESPACE` environment variable for the `keda-operator` container.\n\nDefining a `ClusterTriggerAuthentication` works almost identically to a `TriggerAuthentication`, except there is no `metadata.namespace` value:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: {cluster-trigger-authentication-name}\nspec:\n  # As before ...\n```\n\n## Authentication parameters\n\nAuthentication parameters can be pulled in from many sources. All of these values are merged together to make the authentication data for the scaler.\n\n### Environment variable(s)\n\nYou can pull information via one or more environment variables by providing the `name` of the variable for a given `containerName`.\n\n```yaml\nenv:                              # Optional.\n  - parameter: region             # Required - Defined by the scale trigger\n    name: my-env-var              # Required.\n    containerName: my-container   # Optional. Default: scaleTargetRef.envSourceContainerName of ScaledObject\n```\n\n**Assumptions:** `containerName` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Secret(s)\n\nYou can pull one or more secrets into the trigger by defining the `name` of the Kubernetes Secret and the `key` to use.\n\n```yaml\nsecretTargetRef:                          # Optional.\n  - parameter: connectionString           # Required - Defined by the scale trigger\n    name: my-keda-secret-entity           # Required.\n    key: azure-storage-connectionstring   # Required.\n```\n\n**Assumptions:** `namespace` is in the same resource as referenced by `scaleTargetRef.name` in the ScaledObject, unless specified otherwise.\n\n### Hashicorp Vault secret(s)\n\nYou can pull one or more Hashicorp Vault secrets into the trigger by defining the authentication metadata such as Vault `address` and the `authentication` method (token | kubernetes). If you choose kubernetes auth method you should provide `role` and `mount` as well.\n`credential` defines the Hashicorp Vault credentials depending on the authentication method, for kubernetes you should provide path to service account token (/var/run/secrets/kubernetes.io/serviceaccount/token) and for token auth method provide the token.\n`secrets` list defines the mapping between the path and the key of the secret in Vault to the parameter.\n`namespace` may be used to target a given Vault Enterprise namespace.\n\n```yaml\nhashiCorpVault:                                     # Optional.\n  address: {hashicorp-vault-address}                # Required.\n  namespace: {hashicorp-vault-namespace}            # Optional. Default is root namespace. Useful for Vault Enterprise\n  authentication: token | kubernetes                # Required.\n  role: {hashicorp-vault-role}                      # Optional.\n  mount: {hashicorp-vault-mount}                    # Optional.\n  credential:                                       # Optional.\n    token: {hashicorp-vault-token}                  # Optional.\n    serviceAccount: {path-to-service-account-file}  # Optional.\n  secrets:                                          # Required.\n  - parameter: {scaledObject-parameter-name}        # Required.\n    key: {hashicorp-vault-secret-key-name}           # Required.\n    path: {hashicorp-vault-secret-path}              # Required.\n```\n\n### Azure Key Vault secret(s)\n\nYou can pull secrets from Azure Key Vault into the trigger by using the `azureKeyVault` key.\n\nThe `secrets` list defines the mapping between the key vault secret and the authentication parameter.\n\nYou can use pod identity providers `azure` or `azure-workload` to authenticate to the key vault by specifying it in the\n`TriggerAuthentication` / `ClusterTriggerAuthentication` definition. Pod Identity binding needs to be applied in the keda namespace.\n\nIf you do not wish to use a pod identity provider, you need to register an [application](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals) with Azure Active Directory and specify its credentials. The `clientId` and `tenantId` for the application are to be provided as part of the spec. The `clientSecret` for the application is expected to be within a kubernetes secret in the same namespace as the authentication resource.\n\nEnsure that \"read secret\" permissions have been granted to the managed identity / Azure AD application on the Azure Key Vault. Learn more in the Azure Key Vault [documentation](https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal).\n\nThe `cloud` parameter can be used to specify cloud environments besides `Azure Public Cloud`, such as known Azure clouds like\n`Azure China Cloud`, etc. and even Azure Stack Hub or Air Gapped clouds.\n\n```yaml\nazureKeyVault:                                          # Optional.\n  vaultUri: {key-vault-address}                         # Required.\n  credentials:                                          # Optional. Required when not using pod identity.\n    clientId: {azure-ad-client-id}                      # Required.\n    clientSecret:                                       # Required.\n      valueFrom:                                        # Required.\n        secretKeyRef:                                   # Required.\n          name: {k8s-secret-with-azure-ad-secret}       # Required.\n          key: {key-within-the-secret}                  # Required.\n    tenantId: {azure-ad-tenant-id}                      # Required.\n  cloud:                                                # Optional.\n    type: AzurePublicCloud | AzureUSGovernmentCloud | AzureChinaCloud | AzureGermanCloud | Private # Required.\n    keyVaultResourceURL: {key-vault-resource-url-for-cloud}           # Required when type = Private.\n    activeDirectoryEndpoint: {active-directory-endpoint-for-cloud}    # Required when type = Private.\n  secrets:                                              # Required.\n  - parameter: {param-name-used-for-auth}               # Required.\n    name: {key-vault-secret-name}                       # Required.\n    version: {key-vault-secret-version}                 # Optional.\n```\n\n### Pod Authentication Providers\n\nSeveral service providers allow you to assign an identity to a pod. By using that identity, you can defer authentication to the pod & the service provider, rather than configuring secrets.\n\nCurrently we support the following:\n\n```yaml\npodIdentity:\n  provider: none | azure | azure-workload | aws-eks | aws-kiam  # Optional. Default: none\n  identityId: <identity-id>                                     # Optional. Only used by azure & azure-workload providers.\n```\n\n#### Azure Pod Identity\n\nAzure Pod Identity is an implementation of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity) which lets you bind an [**Azure Managed Identity**](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/) to a Pod in a Kubernetes cluster as delegated access - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Pod Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure           # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: Identity linked with the label set when installing KEDA.\n```\n\nAzure AD Pod Identity will give access to containers with a defined label for `aadpodidbinding`.  You can set this label on the KEDA operator deployment.  This can be done for you during deployment with Helm with `--set podIdentity.activeDirectory.identity={your-label-name}`.\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### Azure Workload Identity\n\n[**Azure AD Workload Identity**](https://github.com/Azure/azure-workload-identity) is the newer version of [**Azure AD Pod Identity**](https://github.com/Azure/aad-pod-identity). It lets your Kubernetes workloads access Azure resources using an\n[**Azure AD Application**](https://docs.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals)\nwithout having to specify secrets, using [federated identity credentials](https://azure.github.io/azure-workload-identity/docs/topics/federated-identity-credential.html) - *Don't manage secrets, let Azure AD do the hard work*.\n\nYou can tell KEDA to use Azure AD Workload Identity via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: azure-workload  # Optional. Default: none\n  identityId: <identity-id> # Optional. Default: ClientId From annotation on service-account.\n```\n\nAzure AD Workload Identity will give access to pods with service accounts having appropriate labels and annotations. Refer\nto these [docs](https://azure.github.io/azure-workload-identity/docs/topics/service-account-labels-and-annotations.html) for more information. You can set these labels and annotations on the KEDA Operator service account. This can be done for you during deployment with Helm with the\nfollowing flags -\n\n1. `--set podIdentity.azureWorkload.enabled=true`\n2. `--set podIdentity.azureWorkload.clientId={azure-ad-client-id}`\n3. `--set podIdentity.azureWorkload.tenantId={azure-ad-tenant-id}`\n\nYou can override the identity that was assigned to KEDA during installation, by specifying an `identityId` parameter under the `podIdentity` field. This allows end-users to use different identities to access various resources which is more secure than using a single identity that has access to multiple resources.\n\n#### AWS EKS Pod Identity Webhook\n\n[**EKS Pod Identity Webhook**](https://github.com/aws/amazon-eks-pod-identity-webhook), which is described more in depth [here](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), allows you to provide the role name using an annotation on a service account associated with your pod.\n\nYou can tell KEDA to use EKS Pod Identity Webhook via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-eks # Optional. Default: none\n```\n\n#### AWS Kiam Pod Identity\n\n[**Kiam**](https://github.com/uswitch/kiam/) lets you bind an AWS IAM Role to a pod using an annotation on the pod.\n\nYou can tell KEDA to use Kiam via `podIdentity.provider`.\n\n```yaml\npodIdentity:\n  provider: aws-kiam # Optional. Default: none\n```\n"
  },
  {
    "path": "content/docs/2.9/concepts/external-scalers.md",
    "content": "+++\ntitle = \"External Scalers\"\nweight = 500\n+++\n\nWhile KEDA ships with a set of [built-in scalers](../scalers), users can also extend KEDA through a [GRPC](https://grpc.io) service that implements the same interface as the built-in scalers.\n\nBuilt-in scalers run in the KEDA process/pod, while external scalers require an externally managed GRPC server that's accessible from KEDA with optional [TLS authentication](https://grpc.io/docs/guides/auth/). KEDA itself acts as a GRPC client and it exposes similar service interface for the built-in scalers, so external scalers can fully replace built-in ones.\n\nThis document describes the external scaler interfaces and how to implement them in Go, Node, and .NET; however for more details on GRPC refer to [the official GRPC documentation](https://grpc.io/docs/)\n\n> Want to learn about existing external scalers? Explore our [external scaler community](https://github.com/kedacore/external-scalers).\n\n## Overview\n\n### Built-in scalers interface\n\nSince external scalers mirror the interface of built-in scalers, it's worth becoming familiar with the Go `interface` that the built-in scalers implement:\n\n```go\n// Scaler interface\ntype Scaler interface {\n\t// GetMetricsAndActivity returns the metric values and activity for a metric Name\n\tGetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error)\n\t// GetMetricSpecForScaling returns the metrics based on which this scaler determines that the ScaleTarget scales. This is used to construct the HPA spec that is created for\n\t// this scaled object. The labels used should match the selectors used in GetMetrics\n\tGetMetricSpecForScaling(ctx context.Context) []v2.MetricSpec\n\t// Close any resources that need disposing when scaler is no longer used or destroyed\n\tClose(ctx context.Context) error\n}\n\n// PushScaler interface\ntype PushScaler interface {\n\tScaler\n\n\t// Run is the only writer to the active channel and must close it once done.\n\tRun(ctx context.Context, active chan<- bool)\n}\n\n```\n\nThe `Scaler` interface defines 3 methods:\n\n- `Close` is called to allow the scaler to clean up connections or other resources.\n- `GetMetricSpecForScaling` returns the target value for the HPA definition for the scaler. For more details refer to [Implementing `GetMetricSpec`](#5-implementing-getmetricspec).\n- `GetMetricsAndActivity` is called on `pollingInterval` and. When activity returns `true`, KEDA will scale to what is returned by the metric limited by `maxReplicaCount` on the ScaledObject/ScaledJob.\n  When `false` is returned, KEDA will scale to `minReplicaCount` or optionally `idleReplicaCount`. More details around the defaults and how these options work together can be found on the [ScaledObjectSpec](https://keda.sh/docs/latest/concepts/scaling-deployments/#scaledobject-spec).\n  > Refer to the [HPA docs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for how HPA calculates `replicaCount` based on metric value and target value. KEDA supports both `AverageValue` and `Value` metric target types for external metrics. When `AverageValue` (the default metric type) is used, the metric value returned by the external scaler will be divided by the number of replicas.\n\nThe `PushScaler` interface adds a `Run` method. This method receives a push channel (`active`), on which the scaler can send `true` at any time. The purpose of this mechanism is to initiate a scaling operation independently from `pollingInterval`.\n\n### External Scaler GRPC interface\n\nKEDA comes with 2 external scalers [`external`](../scalers/external.md) and [`external-push`](../scalers/external-push.md).\n\nThe configuration in the ScaledObject points to a GRPC service endpoint that implements the [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto) GRPC contract:\n\n```proto\nservice ExternalScaler {\n    rpc IsActive(ScaledObjectRef) returns (IsActiveResponse) {}\n    rpc StreamIsActive(ScaledObjectRef) returns (stream IsActiveResponse) {}\n    rpc GetMetricSpec(ScaledObjectRef) returns (GetMetricSpecResponse) {}\n    rpc GetMetrics(GetMetricsRequest) returns (GetMetricsResponse) {}\n}\n```\n\nMuch of this contract is similar to the built-in scalers:\n\n- `GetMetricsSpec` mirrors its counterpart in the `Scaler` interface for creating HPA definition.\n- `IsActive` and `GetMetrics` map to the `GetMetricsAndActivity` method on the `Scaler` interface.\n- `StreamIsActive` maps to the `Run` method on the `PushScaler` interface.\n\nThere are, however, some notable differences:\n\n- There is no `Close` method. The scaler is expected to be functional throughout its lifetime.\n- `IsActive`, `StreamIsActive`, and `GetMetricsSpec` are called with a `ScaledObjectRef` that contains the scaledObject name/namespace as well as the content of `metadata` defined in the trigger.\n\n### Example\n\nGiven the following `ScaledObject`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: service-address.svc.local:9090\n        key1: value1\n        key2: value2\n```\n\nKEDA will attempt a GRPC connection to `service-address.svc.local:9090` immediately after reconciling the `ScaledObject`. It will then make the following RPC calls:\n\n- `IsActive` - KEDA does an initial call to `IsActive` followed by one call on each `pollingInterval`\n- `StreamIsActive` - KEDA does an initial call and the scaler is expected to maintain a long-lived connection (called a `stream` in GRPC terminology). The external push scaler can then send an `IsActive` event back to KEDA at any time. KEDA will only attempt another call to `StreamIsActive` if it needs to re-connect\n- `GetMetricsSpec` - KEDA will do an initial call with the following data in the incoming `ScaledObjectRef` parameter:\n- `GetMetrics` - KEDA will call this method every `pollingInterval` to get the point-in-time metric values for the names returned by `GetMetricsSpec`.\n\n```json\n{\n  \"name\": \"scaledobject-name\",\n  \"namespace\": \"scaledobject-namespace\",\n  \"scalerMetadata\": {\n    \"scalerAddress\": \"service-address.svc.local:9090\",\n    \"key1\": \"value1\",\n    \"key2\": \"value2\"\n  }\n}\n```\n\n> **Note**: KEDA will issue all of the above RPC calls except `StreamIsActive` if `spec.triggers.type` is `external`. It _must_ be `external-push` for `StreamIsActive` to be called.\n\n## Implementing KEDA external scaler GRPC interface\n\n### Implementing an external scaler\n\n#### 1. Download [`externalscaler.proto`](https://github.com/kedacore/keda/blob/main/pkg/scalers/externalscaler/externalscaler.proto)\n\n#### 2. Prepare project\n\n{{< collapsible \"Golang\" >}}\n\n2.1. Download [`./protoc`](https://github.com/protocolbuffers/protobuf/releases) for your platform\n\n2.2. get `protoc-gen-go`\n\n```bash\ngo get github.com/golang/protobuf/protoc-gen-go@v1.3.2\n```\n\n2.3. Prepare project\n\n```bash\ngo mod init example.com/external-scaler/sample\nmkdir externalscaler\nprotoc externalscaler.proto --go_out=plugins=grpc:externalscaler\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n2.1. Create a new project\n\n```bash\ndotnet new console -o ExternalScalerSample\ncd ExternalScalerSample\n\n# add Grpc.AspNetCore\ndotnet add package Grpc.AspNetCore\ndotnet add package Newtonsoft.Json\n\n# Create a Protos and Services folders\nmkdir Protos\nmkdir Services\n```\n\n2.2. Move `externalscaler.proto` to `Protos` folder\n\n2.3. Compile `externalscaler.proto` using this in `ExternalScalerSample.csproj`\n\n```xml\n  <ItemGroup>\n    <Protobuf Include=\"Protos\\externalscaler.proto\" GrpcServices=\"Server\" />\n  </ItemGroup>\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n2.1. Prepare the project\n\n```bash\nnpm install --save grpc request\n```\n\n{{< /collapsible >}}\n\n#### 3. Implementing `IsActive`\n\nJust like `IsActive(ctx context.Context) (bool, error)` in the go interface, the `IsActive` method in the GRPC interface is called every `pollingInterval` with a `ScaledObjectRef` object that contains the scaledObject name, namespace, and scaler metadata.\n\nThis section implements an external scaler that queries earthquakes from [earthquake.usgs.gov](https://earthquake.usgs.gov/) and scales the deployment if there has been more than 2 earthquakes with `magnitude > 1.0` around a particular longitude/latitude in the previous day.\n\nSubmit the following `ScaledObject` to tell KEDA to start making RPC calls to your external scaler (modifying appropriate fields as necessary):\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: scaledobject-name\n  namespace: scaledobject-namespace\nspec:\n  scaleTargetRef:\n    name: deployment-name\n  triggers:\n    - type: external\n      metadata:\n        scalerAddress: earthquake-scaler:9090\n        longitude: \"-122.335167\"\n        latitude: \"47.608013\"\n```\n\n{{< collapsible \"Golang\" >}}\n\nThe full implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `main.go` file:\n\n```golang\nfunc (e *ExternalScaler) IsActive(ctx context.Context, scaledObject *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {\n\t// request.Scalermetadata contains the `metadata` defined in the ScaledObject\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tstartTime := time.Now().AddDate(0, 0, -1).Format(\"2006-01-02\")\n\tendTime := time.Now().Format(\"2006-01-02\")\n\tradiusKM := 500\n\tquery := fmt.Sprintf(\"format=geojson&starttime=%s&endtime=%s&longitude=%s&latitude=%s&maxradiuskm=%d\", startTime, endTime, longitude, latitude, radiusKM)\n\n\tresp, err := http.Get(fmt.Sprintf(\"https://earthquake.usgs.gov/fdsnws/event/1/query?%s\", query))\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tdefer resp.Body.Close()\n\tbody, err := ioutil.ReadAll(resp.Body)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\tpayload := USGSResponse{}\n\terr = json.Unmarshal(body, &payload)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\t// count how many earthquakes with mag > 1.0\n\tcount := 0\n\tfor _, f := range payload.Features {\n\t\tif f.Properties.Mag > 1.0 {\n\t\t\tcount++\n\t\t}\n\t}\n\n\t// return true if there is more than 2\n\treturn &pb.IsActiveResponse{\n\t\tResult: count > 2,\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\nFull implementation can be found at [github.com/kedacore/external-scaler-samples](https://github.com/kedacore/external-scaler-samples).\n\nPut the following code into your `Services/ExternalScalerService.cs` file:\n\n```csharp\npublic class ExternalScalerService : ExternalScaler.ExternalScalerBase\n{\n  private static readonly HttpClient _client = new HttpClient();\n\n  public override async Task<IsActiveResponse> IsActive(ScaledObjectRef request, ServerCallContext context)\n  {\n    // request.Scalermetadata contains the `metadata` defined in the ScaledObject\n    if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n      !request.ScalerMetadata.ContainsKey(\"longitude\")) {\n      throw new ArgumentException(\"longitude and latitude must be specified\");\n    }\n\n    var longitude = request.ScalerMetadata[\"longitude\"];\n    var latitude = request.ScalerMetadata[\"latitude\"];\n    var startTime = DateTime.UtcNow.AddDays(-1).ToString(\"yyyy-MM-dd\");\n    var endTime = DateTime.UtcNow.ToString(\"yyyy-MM-dd\");\n    var radiusKm = 500;\n    var query = $\"format=geojson&starttime={startTime}&endtime={endTime}&longitude={longitude}&latitude={latitude}&maxradiuskm={radiusKm}\";\n\n    var resp = await _client.GetAsync($\"https://earthquake.usgs.gov/fdsnws/event/1/query?{query}\");\n    resp.EnsureSuccessStatusCode();\n    var payload = JsonConvert.DeserializeObject<USGSResponse>(await resp.Content.ReadAsStringAsync());\n\n    return new IsActiveResponse\n    {\n      // return true if there is more than 2 Earthquakes with mag > 1.0\n      Result = payload.features.Count(f => f.properties.mag > 1.0) > 2\n    };\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\nPut the following code into your `index.js` file:\n\n```js\nconst grpc = require(\"grpc\");\nconst request = require(\"request\");\nconst externalScalerProto = grpc.load(\"externalscaler.proto\");\n\nconst server = new grpc.Server();\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  isActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const now = new Date();\n      const yesterday = new Date(new Date().setDate(new Date().getDate() - 1));\n\n      const startTime = `${yesterday.getUTCFullYear()}-${yesterday.getUTCMonth()}-${yesterday.getUTCDay()}`;\n      const endTime = `${now.getUTCFullYear()}-${now.getUTCMonth()}-${now.getUTCDay()}`;\n      const radiusKm = 500;\n      const query = `format=geojson&starttime=${startTime}&endtime=${endTime}&longitude=${longitude}&latitude=${latitude}&maxradiuskm=${radiusKm}`;\n\n      request.get(\n        {\n          url: `https://earthquake.usgs.gov/fdsnws/event/1/query?${query}`,\n          json: true,\n        },\n        (err, resp, data) => {\n          if (err) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: err,\n            });\n          } else if (resp.statusCode !== 200) {\n            callback({\n              code: grpc.status.INTERNAL,\n              details: `expected status 200, got ${resp.statusCode}`,\n            });\n          } else {\n            // count how many earthquakes with mag > 1.0\n            let count = 0;\n            data.features.forEach((i) => {\n              if (i.properties.mag > 1.0) {\n                count++;\n              }\n            });\n            callback(null, {\n              result: count > 2,\n            });\n          }\n        }\n      );\n    }\n  },\n});\n\nserver.bind(\"127.0.0.1:9090\", grpc.ServerCredentials.createInsecure());\nconsole.log(\"Server listening on 127.0.0.1:9090\");\n\nserver.start();\n```\n\n{{< /collapsible >}}\n\n#### 4. Implementing `StreamIsActive`\n\nUnlike `IsActive`, `StreamIsActive` is called once when KEDA reconciles the `ScaledObject`, and expects the external scaler to maintain a long-lived connection and push `IsActiveResponse` objects whenever the scaler needs KEDA to activate the deployment.\n\nThis implementation creates a timer and queries USGS APIs on that timer, effectively ignoring `pollingInterval` set in the scaledObject. Alternatively any other asynchronous event can be used instead of a timer, like an HTTP request, or a network connection.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) StreamIsActive(scaledObject *pb.ScaledObjectRef, epsServer pb.ExternalScaler_StreamIsActiveServer) error {\n\tlongitude := scaledObject.ScalerMetadata[\"longitude\"]\n\tlatitude := scaledObject.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tfor {\n\t\tselect {\n\t\tcase <-epsServer.Context().Done():\n\t\t\t// call cancelled\n\t\t\treturn nil\n\t\tcase <-time.Tick(time.Hour * 1):\n\t\t\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude)\n\t\t\tif err != nil {\n\t\t\t\t// log error\n\t\t\t} else if earthquakeCount > 2 {\n\t\t\t\terr = epsServer.Send(&pb.IsActiveResponse{\n\t\t\t\t\tResult: true,\n\t\t\t\t})\n\t\t\t}\n\t\t}\n\t}\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task StreamIsActive(ScaledObjectRef request, IServerStreamWriter<IsActiveResponse> responseStream, ServerCallContext context)\n{\n  if (!request.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScalerMetadata[\"latitude\"];\n  var key = $\"{longitude}|{latitude}\";\n\n  while (!context.CancellationToken.IsCancellationRequested)\n  {\n    var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n    if (earthquakeCount > 2) {\n      await responseStream.WriteAsync(new IsActiveResponse\n      {\n        Result = true\n      });\n    }\n\n    await Task.Delay(TimeSpan.FromHours(1));\n  }\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  streamIsActive: (call, callback) => {\n    const longitude = call.request.scalerMetadata.longitude;\n    const latitude = call.request.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      const interval = setInterval(() => {\n        getEarthquakeCount((err, count) => {\n          if (err) {\n            console.error(err);\n          } else if (count > 2) {\n            call.write({\n              result: true,\n            });\n          }\n        });\n      }, 1000 * 60 * 60);\n\n      call.on(\"end\", () => {\n        clearInterval(interval);\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 5. Implementing `GetMetricSpec`\n\n`GetMetricSpec` returns the `target` value for [the HPA definition for the scaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). This scaler will define a static target of 10, but the threshold value is often specified in the metadata for other scalers.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetricSpec(context.Context, *pb.ScaledObjectRef) (*pb.GetMetricSpecResponse, error) {\n\treturn &pb.GetMetricSpecResponse{\n\t\tMetricSpecs: []*pb.MetricSpec{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tTargetSize: 10,\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricSpecResponse> GetMetricSpec(ScaledObjectRef request, ServerCallContext context)\n{\n  var resp = new GetMetricSpecResponse();\n\n  resp.MetricSpecs.Add(new MetricSpec\n  {\n    MetricName = \"earthquakeThreshold\",\n    TargetSize = 10\n  });\n\n  return Task.FromResult(resp);\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetricSpec: (call, callback) => {\n    callback(null, {\n      metricSpecs: [\n        {\n          metricName: \"earthquakeThreshold\",\n          targetSize: 10,\n        },\n      ],\n    });\n  },\n});\n```\n\n{{< /collapsible >}}\n\n#### 6. Implementing `GetMetrics`\n\n`GetMetrics` returns the value of the metric referred to from `GetMetricSpec`, in this example it's `earthquakeThreshold`.\n\n{{< collapsible \"Golang\" >}}\n\n```golang\nfunc (e *ExternalScaler) GetMetrics(_ context.Context, metricRequest *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {\n\tlongitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"longitude\"]\n\tlatitude := metricRequest.ScaledObjectRef.ScalerMetadata[\"latitude\"]\n\n\tif len(longitude) == 0 || len(latitude) == 0 {\n\t\treturn nil, status.Error(codes.InvalidArgument, \"longitude and latitude must be specified\")\n\t}\n\n\tearthquakeCount, err := getEarthQuakeCount(longitude, latitude, 1.0)\n\tif err != nil {\n\t\treturn nil, status.Error(codes.Internal, err.Error())\n\t}\n\n\treturn &pb.GetMetricsResponse{\n\t\tMetricValues: []*pb.MetricValue{{\n\t\t\tMetricName: \"earthquakeThreshold\",\n\t\t\tMetricValue: int64(earthquakeCount),\n\t\t}},\n\t}, nil\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"C#\" >}}\n\n```csharp\npublic override async Task<GetMetricsResponse> GetMetrics(GetMetricsRequest request, ServerCallContext context)\n{\n  if (!request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"latitude\") ||\n    !request.ScaledObjectRef.ScalerMetadata.ContainsKey(\"longitude\"))\n  {\n    throw new ArgumentException(\"longitude and latitude must be specified\");\n  }\n\n  var longitude = request.ScaledObjectRef.ScalerMetadata[\"longitude\"];\n  var latitude = request.ScaledObjectRef.ScalerMetadata[\"latitude\"];\n\n  var earthquakeCount = await GetEarthQuakeCount(longitude, latitude);\n\n  var resp = new GetMetricsResponse();\n  resp.MetricValues.Add(new MetricValue\n  {\n    MetricName = \"earthquakeThreshold\",\n    MetricValue_ = earthquakeCount\n  });\n\n  return resp;\n}\n```\n\n{{< /collapsible >}}\n\n{{< collapsible \"Javascript\" >}}\n\n```js\nserver.addService(externalScalerProto.externalscaler.ExternalScaler.service, {\n  // ...\n  getMetrics: (call, callback) => {\n    const longitude = call.request.scaledObjectRef.scalerMetadata.longitude;\n    const latitude = call.request.scaledObjectRef.scalerMetadata.latitude;\n    if (!longitude || !latitude) {\n      callback({\n        code: grpc.status.INVALID_ARGUMENT,\n        details: \"longitude and latitude must be specified\",\n      });\n    } else {\n      getEarthquakeCount((err, count) => {\n        if (err) {\n          callback({\n            code: grpc.status.INTERNAL,\n            details: err,\n          });\n        } else {\n          callback(null, {\n            metricValues: [\n              {\n                metricName: \"earthquakeThreshold\",\n                metricValue: count,\n              },\n            ],\n          });\n        }\n      });\n    }\n  },\n});\n```\n\n{{< /collapsible >}}\n"
  },
  {
    "path": "content/docs/2.9/concepts/scaling-deployments.md",
    "content": "+++\ntitle = \"Scaling Deployments, StatefulSets & Custom Resources\"\nweight = 200\n+++\n\n## Overview\n\n### Scaling of Deployments and StatefulSets\n\nDeployments and StatefulSets are the most common way to scale workloads with KEDA.\n\nIt allows you to define the Kubernetes Deployment or StatefulSet that you want KEDA to scale based on a scale trigger. KEDA will monitor that service and based on the events that occur it will automatically scale your resource out/in accordingly.\n\nBehind the scenes, KEDA acts to monitor the event source and feed that data to Kubernetes and the HPA (Horizontal Pod Autoscaler) to drive rapid scale of a resource.  Each replica of a resource is actively pulling items from the event source.  With KEDA and scaling Deployments/StatefulSet you can scale based on events while also preserving rich connection and processing semantics with the event source (e.g. in-order processing, retries, deadletter, checkpointing).\n\nFor example, if you wanted to use KEDA with an Apache Kafka topic as event source, the flow of information would be:\n\n* When no messages are pending processing, KEDA can scale the deployment to zero.\n* When a message arrives, KEDA detects this event and activates the deployment.\n* When the deployment starts running, one of the containers connects to Kafka and starts pulling messages.\n* As more messages arrive at the Kafka Topic, KEDA can feed this data to the HPA to drive scale out.\n* Each replica of the deployment is actively processing messages.  Very likely, each replica is processing a batch of messages in a distributed manner.\n\n### Scaling of Custom Resources\n\nWith KEDA you can scale any workload defined as any `Custom Resource` (for example `ArgoRollout` [resource](https://argoproj.github.io/argo-rollouts/)). The scaling behaves the same way as scaling for arbitrary Kubernetes `Deployment` or `StatefulSet`.\n\nThe only constraint is that the target `Custom Resource` must define `/scale` [subresource](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource).\n\n## ScaledObject spec\n\nThis specification describes the `ScaledObject` Custom Resource definition which is used to define how KEDA should scale your application and what the triggers are. The `.spec.ScaleTargetRef` section holds the reference to the target resource, ie. `Deployment`, `StatefulSet` or `Custom Resource`. \n\n[`scaledobject_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledobject_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: {scaled-object-name}\nspec:\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n  pollingInterval:  30                               # Optional. Default: 30 seconds\n  cooldownPeriod:   300                              # Optional. Default: 300 seconds\n  idleReplicaCount: 0                                # Optional. Default: ignored, must be less than minReplicaCount \n  minReplicaCount:  1                                # Optional. Default: 0\n  maxReplicaCount:  100                              # Optional. Default: 100\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n  advanced:                                          # Optional. Section to specify advanced options\n    restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n    horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n      name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n      behavior:                                      # Optional. Use to modify HPA's scaling behavior\n        scaleDown:\n          stabilizationWindowSeconds: 300\n          policies:\n          - type: Percent\n            value: 100\n            periodSeconds: 15\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n### Details\n```yaml\n  scaleTargetRef:\n    apiVersion:    {api-version-of-target-resource}  # Optional. Default: apps/v1\n    kind:          {kind-of-target-resource}         # Optional. Default: Deployment\n    name:          {name-of-target-resource}         # Mandatory. Must be in the same namespace as the ScaledObject\n    envSourceContainerName: {container-name}         # Optional. Default: .spec.template.spec.containers[0]\n```\n\nThe reference to the resource this ScaledObject is configured for. This is the resource KEDA will scale up/down and setup an HPA for, based on the triggers defined in `triggers:`.\n\nTo scale Kubernetes Deployments only `name` is needed to be specified, if one wants to scale a different resource such as StatefulSet or  Custom Resource (that defines `/scale` subresource), appropriate `apiVersion` (following standard Kubernetes convention, ie. `{api}/{version}`) and `kind` need to be specified.\n\n`envSourceContainerName` is an optional property that specifies the name of container in the target resource, from which KEDA should try to get environment properties holding secrets etc.  If it is not defined, KEDA will try to get environment properties from the first Container, ie. from `.spec.template.spec.containers[0]`.\n\n**Assumptions:** Resource referenced by `name` (and `apiVersion`, `kind`) is in the same namespace as the ScaledObject\n\n---\n#### pollingInterval\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds.\n\n**Example:** in a queue scenario, KEDA will check the queueLength every `pollingInterval`, and scale the resource up or down accordingly.\n\n---\n#### cooldownPeriod\n```yaml\n  cooldownPeriod:  300 # Optional. Default: 300 seconds\n```\n\nThe period to wait after the last trigger reported active before scaling the resource back to 0. By default, it's 5 minutes (300 seconds).\n\nThe `cooldownPeriod` only applies after a trigger occurs; when you first create your `Deployment` (or `StatefulSet`/`CustomResource`), KEDA will immediately scale it to `minReplicaCount`.  Additionally, the KEDA `cooldownPeriod` only applies when scaling to 0; scaling from 1 to N replicas is handled by the [Kubernetes Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).\n\n**Example:** wait 5 minutes after the last time KEDA checked the queue and it was empty. (this is obviously dependent on `pollingInterval`)\n\n---\n#### idleReplicaCount\n\n```yaml\n  idleReplicaCount: 0   # Optional. Default: ignored, must be less than minReplicaCount \n```\n\n> 💡 **NOTE:** Due to limitations in HPA controller the only supported value for this property is 0, it will not work correctly otherwise. See this [issue](https://github.com/kedacore/keda/issues/2314) for more details.\n>\n> In some cases, you always need at least `n` pod running. Thus, you can omit this property and set `minReplicaCount` to `n`.\n>\n> **Example** You set `minReplicaCount` to 1 and `maxReplicaCount` to 10. If there’s no activity on triggers, the target resource is scaled down to `minReplicaCount` (1). Once there are activities, the target resource will scale base on the HPA rule. If there’s no activity on triggers, the resource is again scaled down to `minReplicaCount` (1).\n\nIf this property is set, KEDA will scale the resource down to this number of replicas. If there's some activity on target triggers KEDA will scale the target resource immediately to `minReplicaCount` and then will be scaling handled by HPA. When there is no activity, the target resource is again scaled down to `idleReplicaCount`. This setting must be less than `minReplicaCount`.\n\n**Example:** If there's no activity on triggers the target resource is scaled down to `idleReplicaCount` (0), once there is an activity the target resource is immediately scaled to `minReplicaCount` (10) and then up to `maxReplicaCount` (100) as needed. If there's no activity on triggers the resource is again scaled down to `idleReplicaCount` (0).\n\n---\n#### minReplicaCount\n```yaml\n  minReplicaCount: 1   # Optional. Default: 0\n```\n\nMinimum number of replicas KEDA will scale the resource down to. By default, it's scale to zero, but you can use it with some other value as well.\n\n---\n#### maxReplicaCount\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThis setting is passed to the HPA definition that KEDA will create for a given resource and holds the maximum number of replicas of the target resource.\n\n---\n#### fallback\n```yaml\n  fallback:                                          # Optional. Section to specify fallback options\n    failureThreshold: 3                              # Mandatory if fallback section is included\n    replicas: 6                                      # Mandatory if fallback section is included\n```\n\nThe `fallback` section is optional. It defines a number of replicas to fall back to if a scaler is in an error state.\n\nKEDA will keep track of the number of consecutive times each scaler has failed to get metrics from its source. Once that value passes the `failureThreshold`, instead of not propagating a metric to the HPA (the default error behaviour), the scaler will, instead, return a normalised metric using the formula:\n```\ntarget metric value * fallback replicas\n```\nDue to the HPA metric being of type `AverageValue` (see below), this will have the effect of the HPA scaling the deployment to the defined number of fallback replicas.\n\n**Example:** When my instance of prometheus is unavailable 3 consecutive times, KEDA will change the HPA metric such that the deployment will scale to 6 replicas.\n\nThere are a few limitations to using a fallback:\n - It only supports scalers whose target is an `AverageValue` metric. Thus, it is **not** supported by the CPU & memory scalers, or by scalers whose metric target type is `Value`. In these cases, it will assume that fallback is disabled.\n - It is only supported by `ScaledObjects` **not** `ScaledJobs`.\n\n---\n#### advanced\n```yaml\nadvanced:\n  restoreToOriginalReplicaCount: true/false        # Optional. Default: false\n```\n\nThis property specifies whether the target resource (`Deployment`, `StatefulSet`,...) should be scaled back to original replicas count, after the `ScaledObject` is deleted. \nDefault behavior is to keep the replica count at the same number as it is in the moment of `ScaledObject's` deletion.\n\nFor example a `Deployment` with `3 replicas` is created, then `ScaledObject` is created and the `Deployment` is scaled by KEDA to `10 replicas`. Then `ScaledObject` is deleted:\n 1. if `restoreToOriginalReplicaCount = false` (default behavior) then `Deployment` replicas count is `10`\n 2. if `restoreToOriginalReplicaCount = true` then `Deployment` replicas count is set back to `3` (the original value)\n\n---\n\n```yaml\nadvanced:\n  horizontalPodAutoscalerConfig:                   # Optional. Section to specify HPA related options\n    name: {name-of-hpa-resource}                   # Optional. Default: keda-hpa-{scaled-object-name}\n    behavior:                                      # Optional. Use to modify HPA's scaling behavior\n      scaleDown:\n        stabilizationWindowSeconds: 300\n        policies:\n        - type: Percent\n          value: 100\n          periodSeconds: 15\n```\n\n##### `horizontalPodAutoscalerConfig`\n\n###### `horizontalPodAutoscalerConfig.name`\n\nThe name of the HPA resource KEDA will create. By default it's `keda-hpa-{scaled-object-name}`\n\n###### `horizontalPodAutoscalerConfig.behavior`\n\nStarting from Kubernetes v1.18 the autoscaling API allows scaling behavior to be configured through the HPA behavior field. This way one can directly affect scaling of 1<->N replicas, which is internally being handled by HPA. KEDA would feed values from this section directly to the HPA's `behavior` field. Please follow [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#configurable-scaling-behavior) for details.\n\n**Assumptions:** KEDA must be running on Kubernetes cluster v1.18+, in order to be able to benefit from this setting.\n\n---\n#### triggers\n```yaml\n  triggers:\n  # {list of triggers to activate scaling of the target resource}\n```\n\n> 💡 **NOTE:** You can find all supported triggers [here](/scalers).\n\nTrigger fields:\n- **type**: The type of trigger to use. (Mandatory)\n- **metadata**: The configuration parameters that the trigger requires. (Mandatory)\n- **name**: Name for this trigger. This value can be used to easily distinguish this specific trigger and its metrics when consuming [Prometheus metrics](../integrations/prometheus.md). By default the name is generated from the trigger type. (Optional)\n- **useCachedMetrics**: ([Experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features)) Enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). For more information, see [\"Caching Metrics (Experimental)\"](#caching-metrics-experimental). (Values: `false`, `true`, Default: `false`, Optional)\n- **authenticationRef**: A reference to the `TriggerAuthentication` or `ClusterTriggerAuthentication` object that is used to authenticate the scaler with the environment.\n  - More details can be found [here](./authentication). (Optional)\n- **metricType**: The type of metric that should be used. (Values: `AverageValue`, `Value`, `Utilization`, Default: `AverageValue`, Optional)\n  - Learn more about how the [Horizontal Pod Autoscaler (HPA) calculates `replicaCount`](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) based on metric type and value.\n  - To show the differences between the metric types, let's assume we want to scale a deployment with 3 running replicas based on a queue of messages:\n    - With `AverageValue` metric type, we can control how many messages, on average, each replica will handle. If our metric is the queue size, the threshold is 5 messages, and the current message count in the queue is 20, HPA will scale the deployment to 20 / 5 = 4 replicas, regardless of the current replica count.\n    - The `Value` metric type, on the other hand, can be used when we don't want to take the average of the given metric across all replicas. For example, with the `Value` type, we can control the average time of messages in the queue. If our metric is average time in the queue, the threshold is 5 milliseconds, and the current average time is 20 milliseconds, HPA will scale the deployment to 3 * 20 / 5 = 12.\n\n> ⚠️ **NOTE:** All scalers, except CPU and Memory, support metric types `AverageValue` and `Value` while CPU and Memory scalers both support `AverageValue` and `Utilization`.\n\n### Caching Metrics (Experimental)\n\n This feature enables caching of metric values during polling interval (as specified in `.spec.pollingInterval`). Kubernetes (HPA controller) asks for a metric every few seconds (as defined by `--horizontal-pod-autoscaler-sync-period`, usually 15s), then this request is routed to KEDA Metrics Server, that by default queries the scaler and reads the metric values. Enabling this feature changes this behavior, KEDA Metrics Server tries to read metric from the cache first. This cache is being updated periodically during the polling interval. \n \n Enabling this feature can significantly reduce the load on the scaler service. \n \n This is an [experimental feature](https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#experimental-features).\n \n This feature is not supported for `cpu`, `memory` or `cron` scaler.\n\n### Pause autoscaling\n\nIt can be useful to instruct KEDA to pause autoscaling of objects, if you want to do to cluster maintenance or you want to avoid resource starvation by removing non-mission-critical workloads. You can enable this by adding the below annotation to your `ScaledObject` definition:\n\n```yaml\nmetadata:\n  annotations:\n    autoscaling.keda.sh/paused-replicas: \"0\"\n```\n\nThe presence of this annotation will pause autoscaling no matter what number of replicas is provided. The above annotation will scale your current workload to 0 replicas and pause autoscaling. You can set the value of replicas for an object to be paused at to any arbitrary number. To enable autoscaling again, simply remove the annotation from the `ScaledObject` definition.\n\n### Activating and Scaling thresholds\n\nTo give a consistent solution to this problem, KEDA has 2 different phases during the autoscaling process.\n\n- **Activation phase:** The activating (or deactivating) phase is the moment when KEDA (operator) has to decide if the workload should be scaled from/to zero. KEDA takes responsibility for this action based on the result of the scaler `IsActive` function and only applies to 0<->1 scaling. There are use-cases where the activating value (0-1 and 1-0) is totally different than 0, such as workloads scaled with the Prometheus scaler where the values go from -X to X.\n- **Scaling phase:** The scaling phase is the moment when KEDA has decided to scale out to 1 instance and now it is the HPA controller who takes the scaling decisions based on the configuration defined in the generated HPA (from ScaledObject data) and the metrics exposed by KEDA (metrics server). This phase applies the to 1<->N scaling.\n\n#### Managing Activation & Scaling Thresholds\n\nKEDA allows you to specify different values for each scenario:\n\n- **Activation:** Defines when the scaler is active or not and scales from/to 0 based on it.\n- **Scaling:** Defines the target value to scale the workload from 1 to _n_ instances and vice versa. To achieve this, KEDA passes the target value to the Horizontal Pod Autoscaler (HPA) and the built-in HPA controller will handle all the autoscaling.\n\n> ⚠️ **NOTE:** If the minimum replicas is >= 1, the scaler is always active and the activation value will be ignored.\n\nEach scaler defines parameters for their use-cases, but the activation will always be the same as the scaling value, appended by the prefix `activation` (ie: `threshold` for scaling and `activationThreshold` for activation).\n\nThere are some important topics to take into account:\n\n- Opposite to scaling value, the activation value is always optional and the default value is 0.\n- Activation only occurs when this value is greater than the set value; not greater than or equal to.\n  - ie, in the default case: `activationThreshold: 0` will only activate when the metric value is 1 or more\n- The activation value has more priority than the scaling value in case of different decisions for each. ie: `threshold: 10` and `activationThreshold: 50`, in case of 40 messages the scaler is not active and it'll be scaled to zero even the HPA requires 4 instances.\n\n> ⚠️ **NOTE:** If a scaler doesn't define \"activation\" parameter (a property that starts with `activation` prefix), then this specific scaler doesn't support configurable activation value and the activation value is always 0.\n\n## Long-running executions\n\nOne important consideration to make is how this pattern can work with long-running executions.  Imagine a deployment triggers on a RabbitMQ queue message.  Each message takes 3 hours to process.  It's possible that if many queue messages arrive, KEDA will help drive scaling out to many replicas - let's say 4.  Now the HPA makes a decision to scale down from 4 replicas to 2.  There is no way to control which of the 2 replicas get terminated to scale down.  That means the HPA may attempt to terminate a replica that is 2.9 hours into processing a 3 hour queue message.\n\nThere are two main ways to handle this scenario.\n\n### Leverage the container lifecycle\n\nKubernetes provides a few [lifecycle hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/) that can be leveraged to delay termination.  Imagine a replica is scheduled for termination and is 2.9 hours into processing a 3 hour message.  Kubernetes will send a [`SIGTERM`](https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html) to signal the intent to terminate.  Rather than immediately terminating, a deployment can delay termination until processing the current batch of messages has completed.  Kubernetes will wait for a `SIGTERM` response or the `terminationGracePeriodSeconds` before killing the replica.\n\n> 💡 **NOTE:** There are other ways to delay termination, including the [`preStop` Hook](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks).\n\nUsing this method can preserve a replica and enable long-running executions.  However, one downside of this approach is while delaying termination, the pod phase will remain in the `Terminating` state.  That means a pod that is delaying termination for a very long duration may show `Terminating` during that entire period of delay.\n\n### Run as jobs\n\nThe other alternative to handling long-running executions is by running the event driven code in Kubernetes Jobs instead of Deployments or Custom Resources.  This approach is discussed [in the next section](../scaling-jobs).\n"
  },
  {
    "path": "content/docs/2.9/concepts/scaling-jobs.md",
    "content": "+++\ntitle = \"Scaling Jobs\"\nweight = 300\n+++\n\n\n## Overview\n\nAs an alternate to [scaling event-driven code as deployments](../scaling-deployments) you can also run and scale your code as Kubernetes Jobs.  The primary reason to consider this option is to handle processing long-running executions.  Rather than processing multiple events within a deployment, for each detected event a single Kubernetes Job is scheduled.  That job will initialize, pull a single event from the message source, and process to completion and terminate.\n\nFor example, if you wanted to use KEDA to run a job for each message that lands on a RabbitMQ queue, the flow may be:\n\n1. When no messages are awaiting processing, no jobs are created.\n1. When a message arrives at the queue, KEDA creates a job.\n1. When the job starts running, it pulls *a single* message and processes it to completion.\n1. As additional messages arrive, additional jobs are created.  Each job processes a single message to completion.\n1. Periodically remove completed/failed job by the `SuccessfulJobsHistoryLimit` and `FailedJobsHistoryLimit.`\n\n## ScaledJob spec\n\nThis specification describes the `ScaledJob` custom resource definition which is used to define how KEDA should scale your application and what the triggers are.\n\n[`scaledjob_types.go`](https://github.com/kedacore/keda/blob/main/apis/keda/v1alpha1/scaledjob_types.go)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: {scaled-job-name}\nspec:\n  jobTargetRef:\n    parallelism: 1                            # [max number of desired pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    completions: 1                            # [desired number of successfully finished pods](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism)\n    activeDeadlineSeconds: 600                #  Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6                           # Specifies the number of retries before marking this job failed. Defaults to 6\n    template:\n      # describes the [job template](https://kubernetes.io/docs/concepts/workloads/controllers/job)\n  pollingInterval: 30                         # Optional. Default: 30 seconds\n  successfulJobsHistoryLimit: 5               # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5                   # Optional. Default: 100. How many failed jobs should be kept.\n  envSourceContainerName: {container-name}    # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n  minReplicaCount: 10                         # Optional. Default: 0\n  maxReplicaCount: 100                        # Optional. Default: 100\n  rolloutStrategy: gradual                    # Deprecated: Use rollout.strategy instead (see below).\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during rollout.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use. \n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n    pendingPodConditions:                     # Optional. A parameter to calculate pending job count per the specified pod conditions\n      - \"Ready\"\n      - \"PodScheduled\"\n      - \"AnyOtherCustomPodCondition\"\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics when multiple scalers are defined.\n  triggers:\n  # {list of triggers to create jobs}\n```\n\nYou can find all supported triggers [here](../scalers).\n\n## Details\n\n```yaml\n  jobTargetRef:\n    parallelism: 1              # Optional. Max number of desired instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    completions: 1              # Optional. Desired number of successfully finished instances ([docs](https://kubernetes.io/docs/concepts/workloads/controllers/job/#controlling-parallelism))\n    activeDeadlineSeconds: 600  # Optional. Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer\n    backoffLimit: 6             # Optional. Specifies the number of retries before marking this job failed. Defaults to 6\n```\n\nThe `jobTargetRef` is a batch/v1 `JobSpec` object; refer to the Kubernetes API for [more details](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/job-v1/#JobSpec) about the fields. The `template` field is required.\n\n---\n\n```yaml\n  pollingInterval: 30  # Optional. Default: 30 seconds\n```\n\nThis is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledJob every 30 seconds.\n\n---\n\n```yaml\n  successfulJobsHistoryLimit: 5  # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 5      # Optional. Default: 100. How many failed jobs should be kept.\n```\n\nThe `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 100.\n\nThis concept is similar to [Jobs History Limits](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#jobs-history-limits) allowing you to learn what the outcomes of your jobs are.\n\nThe actual number of jobs could exceed the limit in a short time. However, it is going to resolve in the cleanup period. Currently, the cleanup period is the same as the Polling interval.\n\n---\n\n\n```yaml\n  envSourceContainerName: {container-name}  # Optional. Default: .spec.JobTargetRef.template.spec.containers[0]\n```\n\nThis optional property specifies the name of container in the Job, from which KEDA should try to get environment properties holding secrets etc. If it is not defined it, KEDA will try to get environment properties from the first Container, ie. from `.spec.JobTargetRef.template.spec.containers[0]`.\n\n___\n```yaml\n  minReplicaCount: 10 # Optional. Default: 0\n```\n\nThe min number of jobs that is created by default. This can be useful to avoid bootstrapping time of new jobs. If minReplicaCount is greater than maxReplicaCount, minReplicaCount will be set to maxReplicaCount.  \n  \nNew messages may create new jobs - within the limits imposed by maxReplicaCount - in order to reach the state where minReplicaCount jobs are always running.  For example, if one sets minReplicaCount to 2 then there will be 2 jobs running permanently. Using a targetValue of 1, if 3 new messages are sent, 2 of those messages will be processed on the already running jobs but another 3 jobs will be created in order to fulfill the desired state dictated by the minReplicaCount parameter that is set to 2.\n___\n\n---\n\n```yaml\n  maxReplicaCount: 100 # Optional. Default: 100\n```\n\nThe max number of pods that is created within a single polling period. If there are running jobs, the number of running jobs will be deducted. This table is an example of the scaling logic.\n\n| Queue Length | Max Replica Count | Target Average Value | Running Job Count | Number of the Scale |\n| ------- | ------ | ------- | ------ | ----- |\n| 10 | 3 | 1 | 0 | 3 |\n| 10 | 3 | 2 | 0 | 3 |\n| 10 | 3 | 1 | 1 | 2 |\n| 10 | 100 | 1 | 0 | 10 | \n| 4 | 3 | 5 | 0 | 1 |\n\n* **Queue Length:** The number of items in the queue.\n* **Target Average Value:** The number of messages that will be consumed on a job. It is defined on the scaler side. e.g. `queueLength` on `Azure Storage Queue` scaler.\n* **Running Job Count:** How many jobs are running.\n* **Number of the Scale:** The number of the job that is created.\n\n---\n\n```yaml\n  rollout:\n    strategy: gradual                         # Optional. Default: default. Which Rollout Strategy KEDA will use.\n    propagationPolicy: foreground             # Optional. Default: background. Kubernetes propagation policy for cleaning up existing jobs during \n```\n\nThe optional property rollout.strategy specifies the rollout strategy KEDA will use while updating an existing ScaledJob.\nPossible values are `default` or `gradual`. \\\nWhen using the `default` rolloutStrategy, KEDA will terminate existing Jobs whenever a ScaledJob is being updated. Then, it will recreate those Jobs with the latest specs. The order in which this termination happens can be configured via the rollout.propagationPolicy property. By default the kubernetes background propagation is used. To change this behavior specify set propagationPolicy to `foreground`. For further information see [Kubernetes Documentation](https://kubernetes.io/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).\nOn the `gradual` rolloutStrategy, whenever a ScaledJob is being updated, KEDA will not delete existing Jobs. Only new Jobs will be created with the latest specs. \n\n\n---\n\n```yaml\nscalingStrategy:\n  strategy: \"default\"                 # Optional. Default: default. Which Scaling Strategy to use. \n```\n\nSelect a Scaling Strategy. Possible values are `default`, `custom`, or `accurate`. The default value is `default`.\n\n> 💡 **NOTE:**\n>\n>`maxScale` is not the running Job count. It is measured as follows:\n >```go\n >maxScale = min(scaledJob.MaxReplicaCount(), divideWithCeil(queueLength, targetAverageValue))\n >```\n >That means it will use the value of `queueLength` divided by `targetAvarageValue` unless it is exceeding the `MaxReplicaCount`.\n>\n>`RunningJobCount` represents the number of jobs that are currently running or have not finished yet.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>\t\trunningJobs++\n>}\n>```\n>`PendingJobCount` provides an indication of the amount of jobs that are in pending state. Pending jobs can be calculated in two ways:\n> - Default behavior - Job that have not finished yet **and** the underlying pod is either not running or has not been completed yet\n> - Setting `pendingPodConditions` - Job that has not finished yet **and** all specified pod conditions of the underlying pod mark as `true` by kubernetes.\n>\n>It is measured as follows:\n>```go\n>if !e.isJobFinished(&job) {\n>   if len(scaledJob.Spec.ScalingStrategy.PendingPodConditions) > 0 {\n>       if !e.areAllPendingPodConditionsFulfilled(&job, scaledJob.Spec.ScalingStrategy.PendingPodConditions) {\n>           pendingJobs++\n>       }\n>   } else {\n>       if !e.isAnyPodRunningOrCompleted(&job) {\n>           pendingJobs++\n>       }\n>   }\n>}\n>```\n\n**default**\nThis logic is the same as Job for V1.  The number of the scale will be calculated as follows. \n\n_The number of the scale_\n\n```go\nmaxScale - runningJobCount\n```\n\n**custom**\nYou can customize the default scale logic. You need to configure the following parameters. If you don't configure it, then the strategy will be `default.`\n\n```yaml\ncustomScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\ncustomScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n```\n\n_The number of the scale_\n\n```go\nmin(maxScale-int64(*s.CustomScalingQueueLengthDeduction)-int64(float64(runningJobCount)*(*s.CustomScalingRunningJobPercentage)), maxReplicaCount)\n```\n\n**accurate** \nIf the scaler returns `queueLength` (number of items in the queue) that does not include the number of locked messages, this strategy is recommended. `Azure Storage Queue` is one example. You can use this strategy if you delete a message once your app consumes it.\n\n```go\nif (maxScale + runningJobCount) > maxReplicaCount {\n\t\treturn maxReplicaCount - runningJobCount\n\t}\n\treturn maxScale - pendingJobCount\n```\nFor more details,  you can refer to [this PR](https://github.com/kedacore/keda/pull/1227).\n\n---\n\n```yaml\nscalingStrategy:\n    multipleScalersCalculation : \"max\" # Optional. Default: max. Specifies how to calculate the target metrics (`queueLength` and `maxScale`) when multiple scalers are defined.\n```\nSelect a behavior if you have multiple triggers. Possible values are `max`, `min`, `avg`, or `sum`. The default value is `max`. \n\n* **max:** - Use metrics from the scaler that has the max number of `queueLength`. (default)\n* **min:** - Use metrics from the scaler that has the min number of `queueLength`.\n* **avg:** - Sum up all the active scalers metrics and divide by the number of active scalers.\n* **sum:** - Sum up all the active scalers metrics.\n\n# Sample\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: rabbitmq-consumer\ndata:\n  RabbitMqHost: <omitted>\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: rabbitmq-consumer\n  namespace: default\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n        - name: demo-rabbitmq-client\n          image: demo-rabbitmq-client:1\n          imagePullPolicy: Always\n          command: [\"receive\",  \"amqp://user:PASSWORD@rabbitmq.default.svc.cluster.local:5672\"]\n          envFrom:\n            - secretRef:\n                name: rabbitmq-consumer-secrets\n        restartPolicy: Never\n    backoffLimit: 4  \n  pollingInterval: 10             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 3   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 2       # Optional. Default: 100. How many failed jobs should be kept.\n  scalingStrategy:\n    strategy: \"custom\"                        # Optional. Default: default. Which Scaling Strategy to use.\n    customScalingQueueLengthDeduction: 1      # Optional. A parameter to optimize custom ScalingStrategy.\n    customScalingRunningJobPercentage: \"0.5\"  # Optional. A parameter to optimize custom ScalingStrategy.\n  triggers:\n  - type: rabbitmq\n    metadata:\n      queueName: hello\n      host: RabbitMqHost\n      queueLength  : '5'\n```\n"
  },
  {
    "path": "content/docs/2.9/concepts/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\nweight = 600\n+++\n\n## KEDA logging and telemetry\n\nThe first place to look if something isn't behaving correctly is the logs generated from KEDA.  After deploying you should have a pod with two containers running within the namespace (by default: `keda`).\n\nYou can view the KEDA operator pod via kubectl:\n\n```sh\nkubectl get pods -n keda\n```\n\nYou can view the logs for the keda operator container with the following:\n\n```sh\nkubectl logs -n keda {keda-pod-name} -c keda-operator\n```\n\n## Reporting issues\n\nIf you are having issues or hitting a potential bug, please file an issue [in the KEDA GitHub repo](https://github.com/kedacore/keda/issues/new/choose) with details, logs, and steps to reproduce the behavior.\n"
  },
  {
    "path": "content/docs/2.9/deploy.md",
    "content": "+++\ntitle = \"Deploying KEDA\"\n+++\n\nWe provide a few approaches to deploy KEDA runtime in your Kubernetes clusters:\n\n- [Helm charts](#helm)\n- [Operator Hub](#operatorhub)\n- [YAML declarations](#yaml)\n\n> 💡 **NOTE:** KEDA requires Kubernetes cluster version 1.23 and higher\n\nDon't see what you need? Feel free to [create an issue](https://github.com/kedacore/keda/issues/new) on our GitHub repo.\n\n## Deploying with Helm {#helm}\n\n### Install\n\nDeploying KEDA with Helm is very simple:\n\n1. Add Helm repo\n\n    ```sh\n    helm repo add kedacore https://kedacore.github.io/charts\n    ```\n\n2. Update Helm repo\n\n    ```sh\n    helm repo update\n    ```\n\n3. Install `keda` Helm chart\n\n    **Helm 3**\n\n    ```sh\n    helm install keda kedacore/keda --namespace keda --create-namespace\n    ```\n\n> 💡 **NOTE:** Are you upgrading to v2.2.1 or above? Make sure to read [our troubleshooting guide](https://keda.sh/docs/latest/troubleshooting/) to fix potential CRD issues.\n\n### Uninstall\n\nIf you want to remove KEDA from a cluster, you first need to remove any ScaledObjects and ScaledJobs that you have created. Once that is done, the Helm chart can be uninstalled:\n\n```sh\nkubectl delete $(kubectl get scaledobjects.keda.sh,scaledjobs.keda.sh -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}')\nhelm uninstall keda -n keda\n```\n\nNote: if you uninstall the Helm chart without first deleting any ScaledObject or ScaledJob resources you have created, they will become orphaned. In this situation, you will need to patch the resources to remove their finalizers. Once this is done, they should automatically be removed:\n\n```sh\nfor i in $(kubectl get scaledobjects -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n\nfor i in $(kubectl get scaledjobs -A \\\n  -o jsonpath='{\"-n \"}{.items[*].metadata.namespace}{\" \"}{.items[*].kind}{\"/\"}{.items[*].metadata.name}{\"\\n\"}');\ndo kubectl patch $i -p '{\"metadata\":{\"finalizers\":null}}' --type=merge\ndone\n```\n\n## Deploying with Operator Hub {#operatorhub}\n\n### Install\n\n1. On Operator Hub Marketplace locate and install KEDA operator to namespace `keda`\n2. Create `KedaController` resource named `keda` in namespace `keda`\n![Operator Hub installation](https://raw.githubusercontent.com/kedacore/keda-olm-operator/main/images/keda-olm-install.gif)\n> 💡 **NOTE:** Further information on Operator Hub installation method can be found in the following [repository](https://github.com/kedacore/keda-olm-operator).\n\n### Uninstall\n\nLocate installed KEDA Operator in `keda` namespace, then remove created `KedaController` resource and uninstall KEDA operator.\n\n## Deploying using the deployment YAML files {#yaml}\n\n### Install\n\nIf you want to try KEDA on [Minikube](https://minikube.sigs.k8s.io) or a different Kubernetes deployment without using Helm you can still deploy it with `kubectl`.\n\n- We provide sample YAML declaration which includes our CRDs and all other resources in a file which is available on the [GitHub releases](https://github.com/kedacore/keda/releases) page.\nRun the following command (if needed, replace the version, in this case `2.9.3`, with the one you are using):\n\n```sh\nkubectl apply -f https://github.com/kedacore/keda/releases/download/v2.9.3/keda-2.9.3.yaml\n```\n\n- Alternatively you can download the file and deploy it from the local path:\n```sh\nkubectl apply -f keda-2.9.3.yaml\n```\n\n- You can also find the same YAML declarations in our `/config` directory on our [GitHub repo](https://github.com/kedacore/keda) if you prefer to clone it.\n\n```sh\ngit clone https://github.com/kedacore/keda && cd keda\n\nVERSION=2.9.3 make deploy\n```\n\n### Uninstall\n\n- In case of installing from released YAML file just run the following command (if needed, replace the version, in this case `2.9.3`, with the one you are using):\n\n```sh\nkubectl delete -f https://github.com/kedacore/keda/releases/download/v2.9.3/keda-2.9.3.yaml\n```\n\n- If you have downloaded the file locally, you can run:\n\n```sh\nkubectl delete -f keda-2.9.3.yaml\n```\n\n- You would need to run these commands from within the directory of the cloned [GitHub repo](https://github.com/kedacore/keda):\n\n```sh\nVERSION=2.9.3 make undeploy\n```\n\n## Deploying KEDA on MicroK8s {#microk8s}\n\n### Install\n\nIf you want to try KEDA v2 on [MicroK8s](https://microk8s.io/) from `1.20` channel, KEDA is included into MicroK8s addons.\n\n```sh\nmicrok8s enable keda\n```\n\n### Uninstall\n\nTo uninstall KEDA in MicroK8s, simply disable the addon as shown below.\n\n```sh\nmicrok8s disable keda\n```\n"
  },
  {
    "path": "content/docs/2.9/integrations/_index.md",
    "content": "+++\ntitle = \"Integrations\"\nweight = 6\n+++\n\nAn overview of tools/products integrating with KEDA:\n\n{{< integrations >}}\n"
  },
  {
    "path": "content/docs/2.9/integrations/prometheus.md",
    "content": "+++\ntitle = \"Integrate with Prometheus\"\ndescription = \"Overview of all Prometheus metrics that KEDA provides\"\navailability = \"v2.0+\"\nproject = \"Prometheus\"\n+++\n\n## Prometheus Exporter Metrics\n\n### Operator\n\nThe KEDA Operator exposes Prometheus metrics which can be scraped on port `8080` at `/metrics`. The following metrics are being gathered:\n\n- `keda_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n- `keda_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_scaled_object_errors`- The number of errors that have occurred for each ScaledObject.\n- `keda_resource_totals` - Total number of KEDA custom resources per namespace for each custom resource type (CRD).\n- `keda_trigger_totals` - Total number of triggers per trigger type.\n- Metrics exposed by the `Operator SDK` framework as explained [here](https://sdk.operatorframework.io/docs/building-operators/golang/advanced-topics/#metrics).\n\n### Metrics Server\n\n> 💡 **DEPRECATED:** Prometheus Metrics exposed from Metrics Server are deprecated, please consume metrics from KEDA Operator.\n\nThe KEDA Metrics Adapter exposes Prometheus metrics which can be scraped on port `9022` (this can be changed by setting the `metrics-port` argument for the Metrics Adapter) at `/metrics`. The metrics collected in the Metrics Adapter are only active when the HPA is active (> 0 replicas).\n\nThe following metrics are being gathered:\n\n- `keda_metrics_adapter_scaler_errors_total` - The total number of errors encountered for all scalers.\n- `keda_metrics_adapter_scaled_object_error_totals`- The number of errors that have occurred for each scaled object.\n- `keda_metrics_adapter_scaler_errors` - The number of errors that have occurred for each scaler.\n- `keda_metrics_adapter_scaler_metrics_value`- The current value for each scaler's metric that would be used by the HPA in computing the target average.\n\n## Premade Grafana dashboard\n\nA premade [Grafana dashboard](https://github.com/kedacore/keda/tree/main/config/grafana/keda-dashboard.json) is available to visualize metrics exposed by the KEDA Metrics Adapter.\n\n![KEDA Grafana dashboard](/img/grafana-dashboard.png)\n\nThe dashboard has two sections:\n\n- Visualization of KEDA's metric server\n- Visualization of the scale target and its changes in replicas scaled by KEDA\n\nOn top, the dashboard supports the following variables:\n\n- datasource\n- namespace\n- scaledObject\n- scaler\n- metric\n"
  },
  {
    "path": "content/docs/2.9/migration.md",
    "content": "+++\ntitle = \"Migration Guide\"\n+++\n\n## Migrating from KEDA v1 to v2\n\nPlease note that you **can not** run both KEDA v1 and v2 on the same Kubernetes cluster. You need to [uninstall](../../1.5/deploy) KEDA v1 first, in order to [install](../deploy) and use KEDA v2.\n\n> 💡 **NOTE:** When uninstalling KEDA v1 make sure v1 CRDs are uninstalled from the cluster as well.\n\nKEDA v2 is using a new API namespace for its Custom Resources Definitions (CRD): `keda.sh` instead of `keda.k8s.io` and introduces a new Custom Resource for scaling of Jobs. See full details on KEDA Custom Resources [here](../concepts/#custom-resources-crd).\n\nHere's an overview of what's changed:\n\n- [Scaling of Deployments](#scaling-of-deployments)\n- [Scaling of Jobs](#scaling-of-jobs)\n- [Improved flexibility & usability of trigger metadata](#improved-flexibility--usability-of-trigger-metadata)\n- [Scalers](#scalers)\n- [TriggerAuthentication](#triggerauthentication)\n\n### Scaling of Deployments\n\nIn order to scale `Deployments` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Rename property `spec.scaleTargetRef.deploymentName` to `spec.scaleTargetRef.name`\n- Rename property `spec.scaleTargetRef.containerName` to `spec.scaleTargetRef.envSourceContainerName`\n- Label `deploymentName` (in `metadata.labels.`) is no longer needed to be specified on v2 ScaledObject (it was mandatory on older versions of v1)\n\nPlease see the examples below or refer to the full [v2 ScaledObject Specification](../concepts/scaling-deployments/#scaledobject-spec)\n\n**Example of v1 ScaledObject**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\n  labels:\n    deploymentName: { deployment-name }\nspec:\n  scaleTargetRef:\n    deploymentName: { deployment-name }\n    containerName: { container-name }\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n**Example of v2 ScaledObject**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledObject\nmetadata: #  <--- labels.deploymentName is not needed\n  name: { scaled-object-name }\nspec:\n  scaleTargetRef:\n    name: { deployment-name } #  <--- Property name was changed\n    envSourceContainerName: { container-name } #  <--- Property name was changed\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to activate the deployment}\n```\n\n### Scaling of Jobs\n\nIn order to scale `Jobs` with KEDA v2, you need to do only a few modifications to existing v1 `ScaledObjects` definitions, so they comply with v2:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n- Change the value of `kind` property from `ScaledObject` to `ScaledJob`\n- Remove property `spec.scaleType`\n- Remove properties `spec.cooldownPeriod` and `spec.minReplicaCount`\n\nYou can configure `successfulJobsHistoryLimit` and `failedJobsHistoryLimit`. They will remove the old job histories automatically.\n\nPlease see the examples below or refer to the full [v2 ScaledJob Specification](../concepts/scaling-jobs/#scaledjob-spec)\n\n**Example of v1 ScaledObject for Jobs scaling**\n\n```yaml\napiVersion: keda.k8s.io/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: { scaled-object-name }\nspec:\n  scaleType: job\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30\n  cooldownPeriod: 300\n  minReplicaCount: 0\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n**Example of v2 ScaledJob**\n\n```yaml\napiVersion: keda.sh/v1alpha1 #  <--- Property value was changed\nkind: ScaledJob #  <--- Property value was changed\nmetadata:\n  name: { scaled-job-name }\nspec: #  <--- spec.scaleType is not needed\n  jobTargetRef:\n    parallelism: 1\n    completions: 1\n    activeDeadlineSeconds: 600\n    backoffLimit: 6\n    template:\n      # {job template}\n  pollingInterval: 30 #  <--- spec.cooldownPeriod and spec.minReplicaCount are not needed\n  successfulJobsHistoryLimit: 5 #  <--- property is added\n  failedJobsHistoryLimit: 5 #  <--- Property is added\n  maxReplicaCount: 100\n  triggers:\n  # {list of triggers to create jobs}\n```\n\n### Improved flexibility & usability of trigger metadata\n\nWe've introduced more options to configure trigger metadata to give users more flexibility.\n\n> 💡 **NOTE:** Changes only apply to trigger metadata and don't impact usage of `TriggerAuthentication`\n\nHere's an overview:\n\n| Scaler               | 1.x                                                                                                             | 2.0                                                                                               |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | -------- |\n| `azure-blob`         | `connection` (**Default**: `AzureWebJobsStorage`)                                                               | `connectionFromEnv`                                                                               |\n| `azure-monitor`      | `activeDirectoryClientId` `activeDirectoryClientPassword`                                                       | `activeDirectoryClientId` `activeDirectoryClientIdFromEnv` `activeDirectoryClientPasswordFromEnv` |\n| `azure-queue`        | `connection` (**Default**: AzureWebJobsStorage)                                                                 | `connectionFromEnv`                                                                               |\n| `azure-servicebus`   | `connection`                                                                                                    | `connectionFromEnv`                                                                               |\n| `azure-eventhub`     | `storageConnection` (**Default**: `AzureWebJobsStorage`) `connection` (**Default**: `EventHub`)                 | `storageConnectionFromEnv` `connectionFromEnv`                                                    |\n| `aws-cloudwatch`     | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-kinesis-stream` | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `aws-sqs-queue`      | `awsAccessKeyID` (**Default**: `AWS_ACCESS_KEY_ID`) `awsSecretAccessKey` (**Default**: `AWS_SECRET_ACCESS_KEY`) | `awsAccessKeyID` `awsAccessKeyIDFromEnv` `awsSecretAccessKeyFromEnv`                              |\n| `kafka`              | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `rabbitmq`           | `apiHost` `host`                                                                                                | ~~`apiHost`~~ `host` `hostFromEnv`                                                                |\n| `prometheus`         | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `cron`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `redis`              | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `redis-streams`      | `address` `host` `port` `password`                                                                              | `address` `addressFromEnv` `host` `hostFromEnv` ~~`port`~~ `passwordFromEnv`                      |\n| `gcp-pubsub`         | `credentials`                                                                                                   | `credentialsFromEnv`                                                                              |\n| `external`           | _(any matching value)_                                                                                          | _(any matching value with `FromEnv` suffix)_                                                      |\n| `liiklus`            | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `stan`               | _(none)_                                                                                                        | _(none)_                                                                                          |\n| `huawei-cloudeye`    |                                                                                                                 | _(none)_                                                                                          | _(none)_ |\n| `postgresql`         | `connection` `password`                                                                                         | `connectionFromEnv` `passwordFromEnv`                                                             |\n| `mysql`              | `connectionString` `password`                                                                                   | `connectionStringFromEnv` `passwordFromEnv`                                                       |\n\n### Scalers\n\n**Azure Service Bus**\n\n- `queueLength` was renamed to `messageCount`\n\n**Kafka**\n\n- `authMode` property was replaced with `sasl` and `tls` properties. Please refer [documentation](../scalers/apache-kafka/#authentication-parameters) for Kafka Authentication Parameters details.\n\n**RabbitMQ**\n\nIn KEDA 2.0 the RabbitMQ scaler has only `host` parameter, and the protocol for communication can be specified by\n`protocol` (http or amqp). The default value is `amqp`. The behavior changes only for scalers that were using HTTP\nprotocol.\n\nExample of RabbitMQ trigger before 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      includeUnacked: \"true\"\n      apiHost: \"https://guest:password@localhost:443/vhostname\"\n```\n\nThe same trigger in 2.0:\n\n```yaml\ntriggers:\n  - type: rabbitmq\n    metadata:\n      queueLength: \"20\"\n      queueName: testqueue\n      protocol: \"http\"\n      host: \"https://guest:password@localhost:443/vhostname\"\n```\n\n### TriggerAuthentication\n\nIn order to use Authentication via `TriggerAuthentication` with KEDA v2, you need to change:\n\n- Change the value of `apiVersion` property from `keda.k8s.io/v1alpha1` to `keda.sh/v1alpha1`\n\nFor more details please refer to the full\n[v2 TriggerAuthentication Specification](../concepts/authentication/#re-use-credentials-and-delegate-auth-with-triggerauthentication)\n"
  },
  {
    "path": "content/docs/2.9/operate/_index.md",
    "content": "+++\ntitle = \"Operate\"\ndescription = \"Guidance & requirements for operating KEDA\"\nweight = 1\n+++\n\nWe provide guidance & requirements around various areas to operate KEDA:\n\n- [Cluster](./cluster)\n- [Kubernetes Events](./events)\n- [KEDA Metrics Server](./metrics-server)\n"
  },
  {
    "path": "content/docs/2.9/operate/cluster.md",
    "content": "+++\ntitle = \"Cluster\"\ndescription = \"Guidance & requirements for running KEDA in your cluster\"\nweight = 100\n+++\n\n## Requirements\n\n### Kubernetes Compatibility\n\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nThe tested window of Kubernetes versions with KEDA follows an \"N-2\" approach, which means each KEDA release is generally tested against N-2 Kubernetes minor versions at minimum.\n\nHowever, maintainers can decide to extend this by testing more minor versions based on the required CRDs in use, but there is no guarantee.\n\nAs a reference, this compatibility matrix shows the Kubernetes versions tested for each KEDA version:\n\n| KEDA | Kubernetes    |\n| ---- | ------------- |\n| v2.9 | v1.23 - v1.25 |\n| v2.8 | v1.17 - v1.25 |\n| v2.7 | v1.17 - v1.25 |\n\n### Cluster Capacity\n\nThe KEDA runtime require the following resources in a production-ready setup:\n\n| Deployment     | CPU                     | Memory                        |\n| -------------- | ----------------------- | ----------------------------- |\n| Metrics Server | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n| Operator       | Limit: 1, Request: 100m | Limit: 1000Mi, Request: 100Mi |\n\nThese are used by default when deploying through YAML.\n\n> 💡 For more info on CPU and Memory resource units and their meaning, see [this](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#resource-units-in-kubernetes) link.\n\n### Firewall\n\nKEDA requires to be accessible inside the cluster to be able to autoscale.\n\nHere is an overview of the required ports that need to be accessible for KEDA to work:\n\n| Port   | Why?                                         | Remarks                                                                                                                                                   |\n| ------ | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `443`  | Used by Kubernetes API server to get metrics | Required for all platforms because it uses Control Plane &#8594; port 443 on the Service IP range communication. This is not applicable for Google Cloud. |\n| `6443` | Used by Kubernetes API server to get metrics | Only required for Google Cloud because it uses Control Plane &#8594; port 6443 on the Pod IP range for communication                                      |\n\n## High Availability\n\nKEDA does not provide full support for high-availability due to upstream limitations.\n\nHere is an overview of all KEDA deployments and the HA notes:\n\n| Deployment     | Support Replicas | Note                                                                                                                                                                                                                                                                                                                                                                                                                                               |\n| -------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Metrics Server | 1                | You can run multiple replicas of our metrics sever, and it is recommended to add the `--enable-aggregator-routing=true` CLI flag to the kube-apiserver so that requests sent to our metrics servers are load balanced. However, [you can only run one active metric server in a Kubernetes cluster serving external.metrics.k8s.io](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) which has to be the KEDA metric server. |\n| Operator       | 2                | While you can run multiple replicas of our operator, only one operator instance will be active. The rest will be standing by, which may reduce downtime during a failure. Multiple replicas will not improve the performance of KEDA, it could only reduce a downtime during a failover.                                                                                                                                                           |\n\n## HTTP Timeouts\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). Each applicable scaler uses its own dedicated HTTP client with its own connection pool, and by default each client is set to time out any HTTP request after 3 seconds.\n\nYou can override this default by setting the `KEDA_HTTP_DEFAULT_TIMEOUT` environment variable on the KEDA operator deployment to your desired timeout in milliseconds.\n\n> ⚠️ All applicable scalers will use this timeout and setting this on a per-scaler is currently not supported.\n\n## HTTP connection disable keep alive\n\nKeep alive behaviour is enabled by default for every HTTP connection, this could stack a huge amount of connections (one per scaler) in some scenarios.\n\nYou can disable keep alive for every HTTP connection by adding the relevant environment variable to both the KEDA Operator, and KEDA Metrics Server deployments:\n\n```yaml\n- env:\n    KEDA_HTTP_DISABLE_KEEP_ALIVE: true\n```\n\nAll applicable scalers will use this keep alive behaviour. Setting a per-scaler keep alive behaviour is currently unsupported.\n\n## HTTP Proxies\n\nSome scalers issue HTTP requests to external servers (i.e. cloud services). As certain companies require external servers to be accessed by proxy servers, adding the relevant environment variables to both the KEDA Operator, and KEDA Metrics Server deployments (HTTP_PROXY, HTTPS_PROXY, NO_PROXY, etc.) would allow the scaler to connect via the desired proxy.\n\n```yaml\n- env:\n    HTTP_PROXY: http://proxy.server:port\n    HTTPS_PROXY: http://proxy.server:port\n    NO_PROXY: 10.0.0.0/8\n```\n\n## Kubernetes Client Parameters\n\nThe Kubernetes client config used within KEDA Operator and KEDA Metrics Adapter can be adjusted by passing the following command-line flags to the binary:\n\n| Adapter Flag        | Client Config Setting  | Default Value | Description                                                                                                                                                   |\n| ------------------- | ---------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| kube-api-qps        | cfg.QPS                | 20.0          | Set the QPS rate for throttling requests sent to the apiserver                                                                                                |\n| kube-api-burst      | cfg.Burst              | 30            | Set the burst for throttling requests sent to the apiserver                                                                                                   |\n| disable-compression | cfg.DisableCompression | true          | Disable compression for response in k8s restAPI in client-go, see [this Kubernetes issue](https://github.com/kubernetes/kubernetes/issues/112296) for details |\n\n## Configure `MaxConcurrentReconciles` for Controllers\n\nTo implement internal controllers KEDA uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime), that enables configuration of [MaxConcurrentReconciles property](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/controller#Options), ie. the maximum number of concurrent reconciles which can be run for a controller.\n\nKEDA Operator exposes properties for specifying `MaxConcurrentReconciles` for following controllers/reconcilers:\n\n- `ScaledObjectReconciler` - responsible for watching and managing `ScaledObjects`, ie. validates input trigger specification, starts scaling logic and manages dependent HPA.\n- `ScaledJobReconciler` - responsible for watching and managing `ScaledJobs` and dependent Kubernetes Jobs\n\nKEDA Metrics Server exposes property for specifying `MaxConcurrentReconciles` for `MetricsScaledObjectReconciler`, that manages Metrics Names exposes by KEDA and which are being consumed by Kubernetes server and HPA controller.\n\nTo modify this properties you can set environment variables on both KEDA Operator and Metrics Server Deployments:\n\n| Environment variable name             | Deployment     | Default Value | Affected reconciler           |\n| ------------------------------------- | -------------- | ------------- | ----------------------------- |\n| KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES | Operator       | 5             | ScaledObjectReconciler        |\n| KEDA_SCALEDJOB_CTRL_MAX_RECONCILES    | Operator       | 1             | ScaledJobReconciler           |\n| KEDA_METRICS_CTRL_MAX_RECONCILES      | Metrics Server | 1             | MetricsScaledObjectReconciler |\n\n## Configure Leader Election\n\nLike reconciliation, KEDA also uses the [controller-runtime project](https://github.com/kubernetes-sigs/controller-runtime) for electing the leader replica. The following properties can be configured for either the Operator and Metrics Server Deployment:\n\n- [`LeaseDuration`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.LeaseDuration)\n- [`RenewDeadline`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RenewDeadline)\n- [`RetryPeriod`](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/manager#Options.RetryPeriod)\n\nTo specify values other than their defaults, you can set the following environment variables:\n\n| Environment variable name                    | Deployment     | Default Value | Manager Property |\n| -------------------------------------------- | -------------- | ------------- | ---------------- |\n| KEDA_OPERATOR_LEADER_ELECTION_LEASE_DURATION | Operator       | 15s           | LeaseDuration    |\n| KEDA_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE | Operator       | 10s           | RenewDeadline    |\n| KEDA_OPERATOR_LEADER_ELECTION_RETRY_PERIOD   | Operator       | 2s            | RetryPeriod      |\n| KEDA_METRICS_LEADER_ELECTION_LEASE_DURATION  | Metrics Server | 15s           | LeaseDuration    |\n| KEDA_METRICS_LEADER_ELECTION_RENEW_DEADLINE  | Metrics Server | 10s           | RenewDeadline    |\n| KEDA_METRICS_LEADER_ELECTION_RETRY_PERIOD    | Metrics Server | 2s            | RetryPeriod      |\n\n## Certificates used by KEDA Metrics Server\n\nBy default KEDA Metrics Server uses self-signed certificates while communicating with Kubernetes API Server. It is recommended to provide own (trusted) certificates instead.\n\nCertificates and CA bundle can be referenced in `args` section in KEDA Metrics Server Deployment:\n\n```yaml\n---\nargs:\n  - \"--client-ca-file=/cabundle/service-ca.crt\"\n  - \"--tls-cert-file=/certs/tls.crt\"\n  - \"--tls-private-key-file=/certs/tls.key\"\n```\n\nThe custom CA bundle should be also referenced in the `v1beta1.external.metrics.k8s.io` [APIService](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/api-service-v1/#APIServiceSpec) resource (which is created during the installation of KEDA).\n\nYou should also make sure that `insecureSkipTLSVerify` is not set to `true`.\n\n```yaml\n---\nspec:\n  service:\n    namespace: keda\n    name: keda-metrics-apiserver\n    port: 443\n  group: external.metrics.k8s.io\n  version: v1beta1\n  caBundle: >-\n    YOURCABUNDLE...\n  groupPriorityMinimum: 100\n  versionPriority: 100\n```\n\n## Restrict Secret Access\n\nBy default, KEDA requires adding `secrets` to the cluster role as following:\n\n```yaml\n- apiGroups:\n    - \"\"\n  resources:\n    - external\n    - pods\n    - secrets\n    - services\n  verbs:\n    - get\n    - list\n    - watch\n```\n\nHowever, this might lead to security risk (especially in production environment) since it will grant permission to read `secrets` from all namespaces.\n\nTo restrict `secret` access and limited to KEDA namespace, you could add `KEDA_RESTRICT_SECRET_ACCESS` as environment variable to both KEDA Operator and KEDA Metrics Server:\n\n```yaml\nenv:\n  - name: KEDA_RESTRICT_SECRET_ACCESS\n    value: \"true\"\n```\n\nThis allows you to omit `secrets` from the cluster role, which will disallow `TriggerAuthentication` to be used for your triggers if the `TriggerAuthentication` is using secrets. You can, however, still use `ClusterTriggerAuthentication`.\n"
  },
  {
    "path": "content/docs/2.9/operate/events.md",
    "content": "+++\ntitle = \"Events\"\ndescription = \"Kubernetes Events emitted by KEDA\"\nweight = 100\n+++\n\n## Kubernetes Events emitted by KEDA\n\nKEDA emits the following [Kubernetes Events](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#event-v1-core):\n\n| Event                                 | Type      | Description                                                                                                                 |\n| ------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------- |\n| `ScaledObjectReady`                   | `Normal`  | On the first time a ScaledObject is ready, or if the previous ready condition status of the object was `Unknown` or `False` |\n| `ScaledJobReady`                      | `Normal`  | On the first time a ScaledJob is ready, or if the previous ready condition status of the object was `Unknown` or `False`    |\n| `ScaledObjectCheckFailed`             | `Warning` | If the check validation for a ScaledObject fails                                                                            |\n| `ScaledJobCheckFailed`                | `Warning` | If the check validation for a ScaledJob fails                                                                               |\n| `ScaledObjectDeleted`                 | `Normal`  | When a ScaledObject is deleted and removed from KEDA watch                                                                  |\n| `ScaledJobDeleted`                    | `Normal`  | When a ScaledJob is deleted and removed from KEDA watch                                                                     |\n| `KEDAScalersStarted`                  | `Normal`  | When Scalers watch loop have started for a ScaledObject or ScaledJob                                                        |\n| `KEDAScalersStopped`                  | `Normal`  | When Scalers watch loop have stopped for a ScaledObject or a ScaledJob                                                      |\n| `KEDAScalerFailed`                    | `Warning` | When a Scaler fails to create or check its event source                                                                     |\n| `KEDAScaleTargetActivated`            | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 1                                       |\n| `KEDAScaleTargetDeactivated`          | `Normal`  | When the scale target (Deployment, StatefulSet, etc) of a ScaledObject is scaled to 0                                       |\n| `KEDAScaleTargetActivationFailed`     | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 1                                                            |\n| `KEDAScaleTargetDeactivationFailed`   | `Warning` | When KEDA fails to scale the scale target of a ScaledObject to 0                                                            |\n| `KEDAJobsCreated`                     | `Normal`  | When KEDA creates jobs for a ScaledJob                                                                                      |\n| `TriggerAuthenticationAdded`          | `Normal`  | When a new TriggerAuthentication is added                                                                                   |\n| `TriggerAuthenticationDeleted`        | `Normal`  | When a TriggerAuthentication is deleted                                                                                     |\n| `ClusterTriggerAuthenticationAdded`   | `Normal`  | When a new ClusterTriggerAuthentication is added                                                                            |\n| `ClusterTriggerAuthenticationDeleted` | `Normal`  | When a ClusterTriggerAuthentication is deleted                                                                              |\n"
  },
  {
    "path": "content/docs/2.9/operate/metrics-server.md",
    "content": "+++\ntitle = \"KEDA Metrics Server\"\ndescription = \"Details on KEDA Metrics Server\"\nweight = 100\n+++\n\n## Querying metrics exposed by KEDA Metrics Server\n\nThe metrics exposed by KEDA Metrics Server can be queried directly using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1\"\n```\n\nThis will return a json with the list of metrics exposed by KEDA:\n```json\n{\n  \"kind\": \"APIResourceList\",\n  \"apiVersion\": \"v1\",\n  \"groupVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"resources\": [\n    {\n      \"name\": \"s0-rabbitmq-queueName\",\n      \"singularName\": \"\",\n      \"namespaced\": true,\n      \"kind\": \"ExternalMetricValueList\",\n      \"verbs\": [\n        \"get\"\n      ]\n    },\n    {\n      \"name\": \"s1-rabbitmq-queueName2\",\n      ....\n    }\n  ]\n}\n```\n\nYou can also query for the value of a specific metric using `kubectl`:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/YOUR_NAMESPACE/YOUR_METRIC_NAME?labelSelector=scaledobject.keda.sh%2Fname%3D{SCALED_OBJECT_NAME}\"\n```\n\nAt this point, you should take in consideration that KEDA metrics are namespaced, this means that you have to specify the namespace where the `ScaledObject` is placed inside.\n\nFor example, if you want to get the value of the metric named `s1-rabbitmq-queueName2`, that is used by ScaledObject named `my-scaled-object` in namespace `sample-ns`, the query will be like this:\n```bash\nkubectl get --raw \"/apis/external.metrics.k8s.io/v1beta1/namespaces/sample-ns/s1-rabbitmq-queueName2?labelSelector=scaledobject.keda.sh%2Fname%3Dmy-scaled-object\"\n```\n\nAnd it will show a json like this:\n\n```json\n{\n  \"kind\": \"ExternalMetricValueList\",\n  \"apiVersion\": \"external.metrics.k8s.io/v1beta1\",\n  \"metadata\": {},\n  \"items\": [\n    {\n      \"metricName\": \"s1-rabbitmq-queueName2\",\n      \"metricLabels\": null,\n      \"timestamp\": \"2021-10-20T10:48:17Z\",\n      \"value\": \"0\"\n    }\n  ]\n}\n```\n\n> **Note:** There are 2 exceptions in querying metrics and those are `cpu` and `memory` scalers. When KEDA creates the HPA object, it uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server. If you want to query these 2 specific values, you should do it using `/apis/metrics.k8s.io/v1beta1` instead of `/apis/external.metrics.k8s.io/v1beta1`.\n\n## How to get metric names from ScaledObject\n\nDuring its work, KEDA updates each ScaledObject with some relevant information which it needs to work. Part of that information is metric names generated from the triggers inside the own ScaledObject.\n\nYou can recover the metric names from a ScaledObject using `kubectl`:\n```bash\n kubectl get scaledobject SCALEDOBJECT_NAME -n NAMESPACE -o jsonpath={.status.externalMetricNames}\n```\n"
  },
  {
    "path": "content/docs/2.9/reference/faq.md",
    "content": "+++\ntitle = \"FAQ\"\n+++\n\n{{< faq20 versionData=\"faq20\" >}}\n"
  },
  {
    "path": "content/docs/2.9/scalers/_index.md",
    "content": "+++\ntitle = \"Scalers\"\nweight = 2\n+++\n\nKEDA **scalers** can both detect if a deployment should be activated or deactivated, and feed custom metrics for a specific event source.\n"
  },
  {
    "path": "content/docs/2.9/scalers/activemq.md",
    "content": "+++\ntitle = \"ActiveMQ\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Queue.\"\ngo_file = \"activemq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `activemq` trigger that scales based on a ActiveMQ Queue.\n\n```yaml\ntriggers:\n- type: activemq\n  metadata:\n    managementEndpoint: \"activemq.activemq-test:8161\"\n    destinationName: \"testQueue\"\n    brokerName: \"activemq_broker\"\n    targetQueueSize: \"100\"\n    activationTargetQueueSize: \"10\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ management endpoint in format: `<hostname>:<port>`.\n- `destinationName` - Name of the queue to check for the message count.\n- `brokerName` - Name of the broker as defined in ActiveMQ.\n- `targetQueueSize` - Target value for queue length passed to the scaler. The scaler will cause the replicas to increase if the queue message count is greater than the target value per active replica. (Default: `10`, Optional)\n- `activationTargetQueueSize` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restAPITemplate` - Template to build REST API url to get queue size. (Default: `\"http://{{.ManagementEndpoint}}/api/jolokia/read/org.apache.activemq:type=Broker,brokerName={{.BrokerName}},destinationType=Queue,destinationName={{.DestinationName}}/QueueSize\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n**Parameter Requirements:**\n\n- In case of `restAPITemplate` parameter is not used, parameters resolving the REST API Template are all **required**: `managementEndpoint`, `destinationName`, `brokerName`.\n- ActiveMQ Scaler polls the ActiveMQ REST API to monitor message count of target queue. Currently, the scaler supports basic authentication. `username` and `password` are **required**. See [Authentication Parameters](#authentication-parameters) below.\n\n### Authentication Parameters\n\nYou can authenticate by using username and password via `TriggerAuthentication` configuration.\n\n**Username and Password based Authentication:**\n\n- `username` - Username for connect to the management endpoint of ActiveMQ.\n- `password` - Password for connect to the management endpoint of ActiveMQ.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: activemq-secret\ntype: Opaque\ndata:\n  activemq-password: ACTIVEMQ_PASSWORD\n  activemq-username: ACTIVEMQ_USERNAME\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-activemq\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: activemq-secret\n    key: activemq-username\n  - parameter: password\n    name: activemq-secret\n    key: activemq-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: activemq-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: activemq\n    metadata:\n      managementEndpoint: \"activemq.activemq-test:8161\"\n      destinationName: \"testQ\"\n      brokerName: \"localhost\"\n      targetQueueSize: \"50\"\n    authenticationRef:\n      name: trigger-auth-activemq\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/apache-kafka.md",
    "content": "+++\ntitle = \"Apache Kafka\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an Apache Kafka topic or other services that support Kafka protocol.\"\ngo_file = \"kafka_scaler\"\n+++\n\n> **Notice:**\n> - By default, the number of replicas will not exceed:\n>   - The number of partitions on a topic when a topic is specified;\n>   - The number of partitions of *all topics* in the consumer group when no topic is specified;\n>   - `maxReplicaCount` specified in `ScaledObject`/`ScaledJob`. If not specified, then the default value of `maxReplicaCount` is taken into account;\n>\n>   That is, if `maxReplicaCount` is set more than number of partitions, the scaler won't scale up to target maxReplicaCount. See `allowIdleConsumers` below to disable this default behavior.\n> - This is so because if there are more number of consumers than the number of partitions in a topic, then extra consumer will have to sit idle.\n\n### Trigger Specification\n\nThis specification describes the `kafka` trigger for an Apache Kafka topic.\n\n```yaml\ntriggers:\n- type: kafka\n  metadata:\n    bootstrapServers: kafka.svc:9092\n    consumerGroup: my-group\n    topic: test-topic\n    lagThreshold: '5'\n    activationLagThreshold: '3'\n    offsetResetPolicy: latest\n    allowIdleConsumers: 'false'\n    scaleToZeroOnInvalidOffset: 'false'\n    excludePersistentLag: 'false'\n    version: 1.0.0\n    partitionLimitation: '1,2,10-20,31'\n```\n\n**Parameter list:**\n\n- `bootstrapServers` - Comma separated list of Kafka brokers \"hostname:port\" to connect to for bootstrap.\n- `consumerGroup` - Name of the consumer group used for checking the offset on the topic and processing the related lag.\n- `topic` - Name of the topic on which processing the offset lag. (Optional, see note below)\n- `lagThreshold` - Target value for the total lag (sum of all partition lags) to trigger scaling actions. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `offsetResetPolicy` - The offset reset policy for the consumer. (Values: `latest`, `earliest`, Default: `latest`, Optional)\n- `allowIdleConsumers` - When set to `true`, the number of replicas can exceed the number of\npartitions on a topic, allowing for idle consumers. (Default: `false`, Optional)\n- `scaleToZeroOnInvalidOffset` - This parameter controls what the scaler does when a partition doesn't have a valid offset.\nIf 'false' (the default), the scaler will keep a single consumer for that partition. Otherwise ('true'), the consumers for that\npartition will be scaled to zero. See the [discussion](https://github.com/kedacore/keda/issues/2612) about this parameter.\n- `excludePersistentLag` - When set to `true`, the scaler will exclude partition lag for partitions which current offset is the same as the current offset of the previous polling cycle. This parameter is useful to prevent scaling due to partitions which current offset message is unable to be consumed. If `false` (the default), scaler will include all consumer lag in all partitions as per normal. (Default: `false`, Optional)\n- `version` - Version of your Kafka brokers. See [sarama](https://github.com/Shopify/sarama) version (Default: `1.0.0`, Optional)\n- `partitionLimitation` - Comma separated list of partition ids to scope the scaling on. Allowed patterns are \"x,y\" and/or ranges \"x-y\". If set, the calculation of the lag will only take these ids into account.  (Default: All partitions, Optional)\n\n> **Note:**\n>\n> When `topic` is unspecified, total offset lag will be calculated with all topics within the consumer group.\n> - When there are **active** consumer instances, _all topics_ includes:\n>   - Topics the consumer is *currently* subscribing to;\n>   - Topics that the consumer group *had prior commit history* (up to retention period for `__consumer_offset`, default to 7 days, see [KIP-186](https://cwiki.apache.org/confluence/display/KAFKA/KIP-186%3A+Increase+offsets+retention+default+to+7+days));\n> - When there are **no active** consumer instances, _all topics_ only includes topics that the consumer group *had prior commit history*;\n> ---\n> An edge case exists where scaling could be **effectively disabled**:\n>    - Consumer never makes a commit (no record in `__consumer_offset`);\n>    - and `ScaledObject` had `minReplicaCount` as 0;\n>\n>   In such case, KEDA could scale the consumer down to 0 when there is no lag and won't be able scale up due to the topic could not be auto discovered.\n>\n> Fix for such case:\n>  - Set `minReplicaCount` > 0;\n>  - or use multiple triggers where one supplies `topic` to ensure lag for that topic will always be detected;\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authenticate by providing `sasl`, `username` and `password`, in case your Kafka cluster has SASL authentication turned on. If you are using SASL/OAuthbearer you will need to provide `oauthTokenEndpointUri` and `scopes` as required by your OAuth2 provider. If TLS is required you should set `tls` to `enable`. If required for your Kafka configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**SASL:**\n\n- `sasl` - Kafka SASL auth mode. (Values: `plaintext`, `scram_sha256`, `scram_sha512`, `oauthbearer` or `none`, Default: `none`, Optional)\n- `username` - Username used for sasl authentication. (Optional)\n- `password` - Password used for sasl authentication. (Optional)\n- `oauthTokenEndpointUri` - The OAuth Access Token URI used for oauthbreaker token requests. (Optional unless sasl mode set to oauthbearer)\n- `scopes` - A comma separated lists of OAuth scopes used in the oauthbreaker token requests. (Optional)\n\n**TLS:**\n\n- `tls` - To enable SSL auth for Kafka, set this to `enable`. If not set, TLS for Kafka is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### New Consumers and Offset Reset Policy\n\nWhen a new Kafka consumer is created, it must determine its consumer group initial position, i.e. the offset it will start to read from. The position is decided in Kafka consumers via a parameter `auto.offset.reset` and the possible values to set are `latest` (Kafka default), and `earliest`. This parameter in KEDA should be set accordingly. In this initial status, no offset has been committed to Kafka for the consumer group and any request for offset metadata will return an `INVALID_OFFSET`; so KEDA has to manage the consumer pod's autoscaling in relation to the offset reset policy that has been specified in the parameters:\n\n- If the policy is set to `earliest` (a new consumer wants to replay everything in the topic from its beginning) and no offset is committed, the scaler will return a lag value equal to the last offset in the topic. In the case of a new topic the last offset will be 0, so it will scale the deployment to 0 replicas. If a new message is produced to the topic, KEDA will return the new value of the offset (1), and will scale the deployments to consume the message.\n- If the policy is set to `latest` (so the new consumer will only consume new messages) and no offset is committed, the scaler will return a negative lag value, and will also tell the HPA to remain `active`, hence the deployment should have the minimum number of replicas running. This is to allow the consumer to read any new message on the topic, and commit its offset.\n\n### Example\n\nYour kafka cluster no SASL/TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n```\n\nYour kafka cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"plaintext\"\n  username: \"admin\"\n  password: \"admin\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n\nYour kafka cluster turn on SASL OAuthbearer/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-kafka-secrets\n  namespace: default\ndata:\n  sasl: \"oauthbearer\"\n  username: \"admin\"\n  password: \"admin\"\n  oauthTokenEndpointUri: \"https://tokenendpoint.com/token\"\n  scopes: \"default\"\n  tls: \"enable\"\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-kafka-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: sasl\n    name: keda-kafka-secrets\n    key: sasl\n  - parameter: username\n    name: keda-kafka-secrets\n    key: username\n  - parameter: password\n    name: keda-kafka-secrets\n    key: password\n  - parameter: oauthTokenEndpointUri\n    name: keda-kafka-secrets\n    key: oauthTokenEndpointUri\n  - parameter: scopes\n    name: keda-kafka-secrets\n    key: scopes\n  - parameter: tls\n    name: keda-kafka-secrets\n    key: tls\n  - parameter: ca\n    name: keda-kafka-secrets\n    key: ca\n  - parameter: cert\n    name: keda-kafka-secrets\n    key: cert\n  - parameter: key\n    name: keda-kafka-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kafka-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-functions-deployment\n  pollingInterval: 30\n  triggers:\n  - type: kafka\n    metadata:\n      bootstrapServers: localhost:9092\n      consumerGroup: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"\n      offsetResetPolicy: latest\n    authenticationRef:\n      name: keda-trigger-auth-kafka-credential\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/artemis.md",
    "content": "+++\ntitle = \"ActiveMQ Artemis\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on ActiveMQ Artemis queues\"\ngo_file = \"artemis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `artemis-queue` trigger for ActiveMQ Artemis queues.\n\n```yaml\ntriggers:\n- type: artemis-queue\n  metadata:\n    managementEndpoint: \"artemis-activemq.artemis:8161\"\n    queueName: \"test\"\n    brokerName: \"artemis-activemq\"\n    brokerAddress: \"test\"\n    queueLength: '10'\n    activationQueueLength: '1'\n    username: 'ARTEMIS_USERNAME'\n    password: 'ARTEMIS_PASSWORD'\n    restApiTemplate: # Optional. Default : \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n```\n\n**Parameter list:**\n\n- `managementEndpoint` - ActiveMQ Artemis management endpoint to connect to in `<hostname>:<port>` format.\n- `queueName` - Name of the queue to check for the number of messages available.\n- `brokerName` - Name of the broker as defined in Artemis.\n- `brokerAddress` - Address of the broker.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (default: 10)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `restApiTemplate` - Template to build REST API url to get queue size. (Default: `\"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"`, Optional)\n- `corsHeader` - Value to populate the Origin header field for CORS filtering. (Default: `\"http://<<managmentEndpoint>>\"`, Optional)\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the `username` and `password` to connect to the management endpoint.\n\n**Username and Password based authentication:**\n\n- `username` - The username to use to connect to the broker's management endpoint.\n- `password` - The password to use to connect to the broker's management endpoint.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedartemis\n  namespace: kedartemis\n  labels:\n    app: kedartemis\ntype: Opaque\ndata:\n  artemis-password: \"YXJ0ZW1pcw==\"\n  artemis-username: \"YXJ0ZW1pcw==\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedartemis\n  namespace: kedartemis\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: kedartemis\n      key: artemis-username\n    - parameter: password\n      name: kedartemis\n      key: artemis-password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedartemis-consumer-scaled-object\n  namespace: kedartemis\nspec:\n  scaleTargetRef:\n    name: kedartemis-consumer\n  triggers:\n    - type: artemis-queue\n      metadata:\n        managementEndpoint: \"artemis-activemq.artemis:8161\"\n        queueName: \"test\"\n        queueLength: \"50\"\n        brokerName: \"artemis-activemq\"\n        brokerAddress: \"test\"\n        restApiTemplate: # Optional. Default: \"http://<<managementEndpoint>>/console/jolokia/read/org.apache.activemq.artemis:broker=\\\"<<brokerName>>\\\",component=addresses,address=\\\"<<brokerAddress>>\\\",subcomponent=queues,routing-type=\\\"anycast\\\",queue=\\\"<<queueName>>\\\"/MessageCount\"\n      authenticationRef:\n        name: trigger-auth-kedartemis\n```"
  },
  {
    "path": "content/docs/2.9/scalers/aws-cloudwatch.md",
    "content": "+++\ntitle = \"AWS CloudWatch\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS CloudWatch.\"\ngo_file = \"aws_cloudwatch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-cloudwatch` trigger that scales based on a AWS CloudWatch.\n\n```yaml\ntriggers:\n- type: aws-cloudwatch\n  metadata:\n    # Required: namespace\n    namespace: AWS/SQS\n    # Optional: Dimension Name\n    dimensionName: QueueName\n    # Optional: Dimension Value\n    dimensionValue: keda\n    # Optional: Expression query\n    expression: SELECT MAX(\"ApproximateNumberOfMessagesVisible\") FROM \"AWS/SQS\" WHERE QueueName = 'keda'\n    metricName: ApproximateNumberOfMessagesVisible\n    targetMetricValue: \"2.1\"\n    minMetricValue: \"1.5\"\n    # Required: region\n    awsRegion: \"eu-west-1\"\n    # Optional: AWS endpoint url\n    awsEndpoint: \"\"\n    # Optional: AWS Access Key ID, can use TriggerAuthentication as well\n    awsAccessKeyIDFromEnv: AWS_ACCESS_KEY_ID # default AWS_ACCESS_KEY_ID\n    # Optional: AWS Secret Access Key, can use TriggerAuthentication as well\n    awsSecretAccessKeyFromEnv: AWS_SECRET_ACCESS_KEY # default AWS_SECRET_ACCESS_KEY\n    identityOwner: pod | operator # Optional. Default: pod\n    # Optional: Collection Time\n    metricCollectionTime: \"300\" # default 300\n    # Optional: Metric Statistic\n    metricStat: \"Average\" # default \"Average\"\n    # Optional: Metric Statistic Period\n    metricStatPeriod: \"300\" # default 300\n    # Optional: Metric Unit\n    metricUnit: \"Count\" # default \"\"\n    # Optional: Metric EndTime Offset\n    metricEndTimeOffset: \"60\" # default 0\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the AWS Cloudwatch.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `dimensionName` - Supports specifying multiple dimension names by using \";\" as a separator i.e. dimensionName: QueueName;QueueName (Optional, Required when `expression` is not specified)\n- `dimensionValue` - Supports specifying multiple dimension values by using \";\" as a separator i.e. dimensionValue: queue1;queue2 (Optional, Required when `expression` is not specified)\n- `expression` - Supports query with [expression](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-querylanguage.html) (Optional, Required when `dimensionName` & `dimensionValue` are not specified)\n\n- `identityOwner` - Receive permissions for CloudWatch via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the CloudWatch. Additional Authentication Parameters are not required.\n\n- `metricCollectionTime` - How long in the past (seconds) should the scaler check AWS Cloudwatch. Used to define **StartTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). The value of `metricCollectionTime` must be greater than the `metricStatPeriod`, providing a value which is a multiple of the `metricStatPeriod` can improve performance on fetching data from Cloudwatch. In practice setting `metricCollectionTime` 2-to-3 times more than the `metricStatPeriod` value can make sure the scaler is able to get data points back from Cloudwatch, the scaler will always use the most up-to-date datapoint if more datapoints are returned. (Default: `300`, Optional)\n- `metricStat` - Which statistics metric to be used by the query. Used to define **Stat** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Statistic)). (Default: `Average`, Optional)\n- `metricStatPeriod` - Which frequency to be used by the related query. Used to define **Period**. The value cannot be an arbitrary number, it must be a value supported by Cloudwatch (1, 5, 10, 30, or a multiple of 60). More details can be found from ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#CloudWatchPeriods)). (Default: `300`, Optional)\n- `metricUnit` - Which unit to be used by the query. Used to define **Unit** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Unit)). (Default: `none`, Optional)\n- `metricEndTimeOffset` - How long in seconds to offset the **EndTime** ([official documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)). Due to the eventual consistency model which is used by Cloudwatch, the latest datapoint one can get from Cloudwatch might not be accurate. The `metricEndTimeOffset` config provides a way to skip the most recent datapoint if needed. (Default: `0`, Optional)\n- `minMetricValue`- Returned value in case of empty response from cloudwatch. (Default: 0, This value can be a float)\n- `targetMetricValue`- Target value for the metric. (Default: 0, This value can be a float)\n- `activationTargetMetricValue`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure authentication by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read data from AWS CloudWatch.\n\n### IAM Permissions\n\nThe user or role used to authenticate with AWS CloudWatch must have the `cloudwatch:GetMetricData` permissions. The following is an example IAM policy that grants the necessary permissions to read data from CloudWatch:\n\n```json\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowCloudWatchGetMetricData\",\n      \"Effect\": \"Allow\",\n      \"Action\": \"cloudwatch:GetMetricData\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n```\n\nFor more information, see the [AWS CloudWatch IAM documentation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html).\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-cloudwatch-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-cloudwatch\n    metadata:\n      namespace: AWS/SQS\n      dimensionName: QueueName\n      dimensionValue: keda\n      metricName: ApproximateNumberOfMessagesVisible\n      targetMetricValue: \"2.1\"\n      minMetricValue: \"0\"\n      awsRegion: \"eu-west-1\"\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/aws-dynamodb-streams.md",
    "content": "+++\ntitle = \"AWS DynamoDB Streams\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS DynamoDB Streams\"\ngo_file = \"aws_dynamodb_streams_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-dynamodb-streams` trigger that scales based on the shard count of AWS DynamoDB Streams.\n\n```yaml\ntriggers:\n- type: aws-dynamodb-streams\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"ap-northeast-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Optional targetValue\n    shardCount: \"2\"\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target DynamoDB table to which the stream belongs.\n- `shardCount` - The target value that a DynamoDB streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `identityOwner` - Receive permissions on the DynamoDB and DynamoDB Streams via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB and Dynamodb Streams. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS DynamoDB and DynamoDB Streams.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id>       # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key>       # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-streams-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb-streams\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: ap-northeast-1\n      tableName: keda-events\n      shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/aws-dynamodb.md",
    "content": "+++\ntitle = \"AWS DynamoDB\"\navailability = \"v2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the records count in AWS DynamoDB\"\ngo_file = \"aws_dynamodb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the AWS DynamoDB scaler. This scaler uses a specified DynamoDB query to determine if and when to scale a given workload.\n\n```yaml\ntriggers:\n- type: aws-dynamodb\n  metadata:\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Required: tableName\n    tableName: myTableName\n    # Required: targetValue\n    targetValue: \"1\"\n    # Required: expressionAttributeNames\n    expressionAttributeNames: '{ \"#k\" : \"partition_key_name\"}'\n    # Required: keyConditionExpression\n    keyConditionExpression: \"#k = :key\"\n    # Required: expressionAttributeValues\n    expressionAttributeValues: '{ \":key\" : {\"S\":\"partition_key_target_value\"}}'\n    # Optional. Default: pod\n    identityOwner: pod | operator\n```\n\n**Parameter list:**\n\n- `awsRegion` - AWS Region for the DynamoDB Table.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `tableName` - The target table where the scaler execute the query.\n- `targetValue` - The target value for the number of items retrieved by the query.\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `expressionAttributeNames` - one or more substitution tokens for attribute names in an expression. Defined as JSON.\n- `keyConditionExpression` - the condition that specifies the key values for items to be retrieved by the Query action.\n- `expressionAttributeValues` - one or more values that can be substituted in an expression. Defined as JSON.\n- `identityOwner` - Receive permissions on the DynamoDB Table via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the DynamoDB Table. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using IAM Role\n\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:  aws-dynamodb-table-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-dynamodb\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      awsRegion: eu-west-2\n      tableName: keda-events\n      expressionAttributeNames: '{ \"#k\" : \"event_type\"}'\n      keyConditionExpression: \"#k = :key\"\n      expressionAttributeValues: '{ \":key\" : {\"S\":\"scaling_event\"}}'\n      targetValue: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/aws-kinesis.md",
    "content": "+++\ntitle = \"AWS Kinesis Stream\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS Kinesis Stream.\"\ngo_file = \"aws_kinesis_stream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-kinesis-stream` trigger that scales based on the shard count of AWS Kinesis Stream.\n\n```yaml\ntriggers:\n- type: aws-kinesis-stream\n  metadata:\n    # Required\n    streamName: myKinesisStream\n    # Required\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    # Optional: Default: 2\n    shardCount: \"2\"\n    identityOwner: pod | operator # Optional. Default: pod\n```\n\n**Parameter list:**\n\n- `streamName` - Name of AWS Kinesis Stream.\n- `shardCount` - The target value that a Kinesis data streams consumer can handle. (Default: `2`, Optional)\n- `activationShardCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `awsRegion` - AWS Region for the Kinesis Stream.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the Kinesis Stream via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the Kinesis Stream. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials, or use other [KEDA supported authentication methods](https://keda.sh/concepts/authentication).\n\n#### Delegate auth with TriggerAuthentication\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need `DescribeStreamSummary` IAM permission policy to read data from AWS Kinesis Streams.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\n  namespace: keda-test\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-kinesis-stream-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n    - type: aws-kinesis-stream\n      authenticationRef:\n        name: keda-trigger-auth-aws-credentials\n      metadata:\n        # Required\n        streamName: myKinesisStream\n        # Required\n        awsRegion: \"eu-west-1\"\n        # Optional: Default: 2\n        shardCount: \"2\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/aws-sqs.md",
    "content": "+++\ntitle = \"AWS SQS Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on AWS SQS Queue.\"\ngo_file = \"aws_sqs_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `aws-sqs-queue` trigger that scales based on an AWS SQS Queue.\n\n```yaml\ntriggers:\n- type: aws-sqs-queue\n  metadata:\n    # Required: queueURL or queueURLFromEnv. If both provided, uses queueURL\n    queueURL: https://sqs.eu-west-1.amazonaws.com/account_id/QueueName\n    queueURLFromEnv: QUEUE_URL # Optional. You can use this instead of `queueURL` parameter\n    queueLength: \"5\"  # Default: \"5\"\n    # Required: awsRegion\n    awsRegion: \"eu-west-1\"\n    # Optional: awsEndpoint\n    awsEndpoint: \"\"\n    identityOwner: pod | operator # Optional. Default: pod\n    \n```\n\n**Parameter list:**\n\n- `queueURL` - Full URL for the SQS Queue. The simple name of the queue can be used in case there's no ambiguity. (Optional, You can use this instead of `queueURLFromEnv` parameter)\n- `queueURLFromEnv` - Name of the environment variable on the scale target to read the queue URL from. (Optional, You can use this instead of `queueURL` parameter)\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual messages in the SQS Queue is 30, the scaler scales to 3 pods. (default: 5)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n> For the purposes of scaling, the default formula for \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. If you wish to only scale on `ApproximateNumberOfMessages` set `scaleOnInFlight` to `false`.\n\n- `scaleOnInFlight` - Indication whether or not to scale on queued messages or to include in-flight messages as well.\n  - When set to `false` \"actual messages\" is equal to `ApproximateNumberOfMessages`. When set to `true` \"actual messages\" is equal to `ApproximateNumberOfMessages` + `ApproximateNumberOfMessagesNotVisible`, since `NotVisible` in SQS terms means the message is still in-flight/processing. (default: true)\n- `awsRegion` - AWS Region for the SQS Queue.\n- `awsEndpoint` - Endpoint URL to override the default AWS endpoint. (Default: `\"\"`, Optional)\n- `identityOwner` - Receive permissions on the SQS Queue via Pod Identity or from the KEDA operator itself (see below). (Values: `pod`, `operator`, Default: `pod`, Optional)\n\n> When `identityOwner` set to `operator` - the only requirement is that the KEDA operator has the correct IAM permissions on the SQS queue. Additional Authentication Parameters are not required.\n\n### Authentication Parameters\n\n> These parameters are relevant only when `identityOwner` is set to `pod`.\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing either a role ARN or a set of IAM credentials.\n\n**Pod identity based authentication:**\n\n- `podIdentity.provider` - Needs to be set to either `aws-kiam` or `aws-eks` on the `TriggerAuthentication` and the pod/service account must be configured correctly for your pod identity provider.\n\n**Role based authentication:**\n\n- `awsRoleArn` - Amazon Resource Names (ARNs) uniquely identify AWS resource.\n\n**Credential based authentication:**\n\n- `awsAccessKeyID` - Id of the user.\n- `awsSecretAccessKey` - Access key for the user to authenticate with.\n- `awsSessionToken` - Session token, only required when using [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html).\n\nThe user will need access to read properties from the specified AWS SQS queue.\n\n### Example\n\n#### Scaling a deployment using podIdentity providers\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  podIdentity:\n    provider: aws-kiam # or aws-eks when using IRSA\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling a deployment using IAM Role\n\nWhen you need to specify the IAM Role used to access the sqs queue.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ROLE_ARN: <encoded-iam-role-arn>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsRoleArn    # The property in KEDA.\n    name: test-secrets       # The name of the kubernetes secret.\n    key: AWS_ROLE_ARN        # The key from the kubernetes secret.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n\n#### Scaling a deployment using IAM Users\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n```\n\n#### Scaling on ApproximateNumberOfMessages only\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: test-secrets\ndata:\n  AWS_ACCESS_KEY_ID: <encoded-user-id> # Required.\n  AWS_SECRET_ACCESS_KEY: <encoded-key> # Required.\n  AWS_SESSION_TOKEN: <encoded-session-token> # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-aws-credentials\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: awsAccessKeyID     # Required.\n    name: test-secrets            # Required.\n    key: AWS_ACCESS_KEY_ID        # Required.\n  - parameter: awsSecretAccessKey # Required.\n    name: test-secrets            # Required.\n    key: AWS_SECRET_ACCESS_KEY    # Required.\n  - parameter: awsSessionToken    # Required when using temporary credentials.\n    name: test-secrets            # Required when using temporary credentials.\n    key: AWS_SESSION_TOKEN        # Required when using temporary credentials.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: aws-sqs-queue-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: aws-sqs-queue\n    authenticationRef:\n      name: keda-trigger-auth-aws-credentials\n    metadata:\n      queueURL: myQueue\n      queueLength: \"5\"\n      awsRegion: \"eu-west-1\"\n      scaleOnInFlight: false\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-app-insights.md",
    "content": "+++\ntitle = \"Azure Application Insights\"\navailability = \"v2.6+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Application Insights metrics.\"\ngo_file = \"azure_app_insights_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-app-insights` trigger that scales based on an Azure Application Insights metric.\n\n```yaml\ntriggers:\n- type: azure-app-insights\n  metadata:\n    metricAggregationTimespan: \"0:1\"\n    metricAggregationType: avg\n    metricFilter: cloud/roleName eq 'role_name'\n    metricId: \"customMetrics/example-metric\"\n    targetValue: \"1.5\"\n    activationTargetValue: \"5.5\"\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    applicationInsightsIdFromEnv: APP_ID # Optional, can use TriggerAuthentication as well\n    tenantIdFromEnv: TENANT_ID` # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    appInsightsResourceURL: https://api.applicationinsights.airgap.io/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\nThis scaler is backed by the Azure Application Insights REST API. Please see [this](https://docs.microsoft.com/en-us/rest/api/application-insights/metrics/get) page\nfor further details.\n\n**Parameter list:**\n\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `metricId` - The name of the Application Insights metric to query. Use the [Azure Command Line Interface](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) to run `az monitor app-insights metrics get-metadata` to see a list of available metrics.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Application Insights metric. The aggregation methods vary from metric to metric. The `az monitor app-insights metrics get-metadata` command can be used to determine which methods apply to a given metric. (Some common aggregation methods are `avg`, `count`, `sum`, `min`, and `max`)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm\"`.\n- `applicationInsightsId` - Id of the Application Insights instance to query. This is a GUID that can be retrieved from the Application Insight's `API Access` blade in the Azure Portal.\n- `activeDirectoryClientId` - Id of the Active Directory client. The client must have `Monitoring Reader` permissions for the Application Insights instance.\n- `activeDirectoryClientPassword` - Password of the Active Directory client password.\n- `metricFilter` - Further specify the metrics query using a filter. For example `cloud/roleName eq 'example`. (Optional)\n- `cloud` - Name of the cloud environment that the Azure Application Insights instance belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `appInsightsResourceURL` - Application Insights REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.applicationinsights.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters can be provided using environment variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Name of the environment variable that contains the Id of the Active Directory application. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the Active Directory client password. (Optional)\n- `applicationInsightsIdFromEnv` - Name of the environment variable that contains the Application Insights Id. (Optional)\n- `tenantIdFromEnv` - Name of the environment variable that contains the Id of the tenant that contains the Application Insights instance. (Optional)\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n- `applicationInsightsId` - Id of the Application Insights instance to query.\n- `tenantId` - Id of the tenant that contains the Azure resource.\n\nThe principal will need `Monitoring Reader` access to query metrics from the Application Insights instance.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used in place of credential based authentication. The following section contains an example of a `TriggerAuthentication` using pod identity.\n\n### Example\n\nThe following example illustrates the use of a TriggerAuthentication to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-app-insights-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-app-insights-secrets\n      key: activeDirectoryClientPassword\n    - parameter: applicationInsightsId\n      name: azure-app-insights-secrets\n      key: applicationInsightsId\n    - parameter: tenantId\n      name: azure-app-insights-secrets\n      key: tenantId\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-app-insights\n    metadata:\n      metricId: \"customMetrics/example-metric\"\n      metricAggregationTimespan: \"0:5\"\n      metricAggregationType: avg\n      metricFilter: cloud/roleName eq 'example'\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-app-insights-trigger-auth\n```\n\nThe following example illustrates the use of environment variables to connect to Application Insights.\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-app-insights-secrets\ntype: Opaque\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n  applicationInsightsId: <appInsightsAppId>\n  tenantId: <tenantId>\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-app-insights-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-app-insights-example\n  template:\n    metadata:\n      labels:\n        app: azure-app-insights-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: ACTIVE_DIRECTORY_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientId\n        - name: ACTIVE_DIRECTORY_PASSWORD\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: activeDirectoryClientPassword\n        - name: APP_INSIGHTS_APP_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: applicationInsightsId\n        - name: TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-app-insights-secrets\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-app-insights-scaler\nspec:\n  scaleTargetRef:\n    name: azure-app-insights-example\n  pollingInterval: 5\n  cooldownPeriod: 5\n  minReplicaCount: 0\n  maxReplicaCount: 2\n  triggers:\n    - type: azure-app-insights\n      metadata:\n        metricId: \"customMetrics/example-metric\"\n        metricAggregationTimespan: \"0:5\"\n        metricAggregationType: avg\n        metricFilter: cloud/roleName eq 'example'\n        targetValue: \"1\"\n        activeDirectoryClientIdFromEnv: ACTIVE_DIRECTORY_ID\n        activeDirectoryClientPasswordFromEnv: ACTIVE_DIRECTORY_PASSWORD\n        applicationInsightsIdFromEnv: APP_INSIGHTS_APP_ID\n        tenantIdFromEnv: TENANT_ID\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-data-explorer.md",
    "content": "+++\ntitle = \"Azure Data Explorer\"\navailability = \"v2.7+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Data Explorer query result.\"\ngo_file = \"azure_data_explorer_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-data-explorer` trigger that scales based on an Azure Data Explorer query result.\n\n```yaml\ntriggers:\n- type: azure-data-explorer\n  metadata:\n    endpoint: https://keda.eastus.kusto.windows.net\n    databaseName: kedadb\n    query: |\n      StormEvents\n      | summarize StormCount = count() by State\n      | top 1 by StormCount desc\n    threshold: \"10.5\"\n    activationThreshold: \"10.5\"\n    tenantId: 045ef409-6dee-4893-a824-5612eac467b1 # Can use TriggerAuthentication as well\n    clientId: 4ba039f1-d69c-434e-9268-4a2bb7bba90d # Can use TriggerAuthentication as well\n    clientSecret: t0p-s3cret  # Can use TriggerAuthentication as well\n    # Alternatively, you can use existing environment variables to read aad app creds from:\n    clientIdFromEnv: AAD_APP_CLIENT_ID_ENV_VAR_NAME # Optional. You can use this instead of `clientId` parameter.\n    clientSecretFromEnv: AAD_APP_SECRET_ENV_VAR_NAME # Optional. You can use this instead of `clientSecret` parameter.\n    tenantIdFromEnv: AAD_APP_TENANT_ID_ENV_VAR_NAME # Optional. You can use this instead of `tenantId` parameter.\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `endpoint` - The endpoint to query your Data Explorer Cluster.\n- `databaseName` - The name of the Data Explorer Database to query.\n- `query` - Data Explorer query.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantId` - Id of the Azure AD tenant.\n- `clientId` - Id of the Azure AD application.\n- `clientSecret` - Password of the Azure AD application.\n- `cloud` - Name of the cloud environment that the Azure Data Explorer cluster belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure AD tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores application id of your Azure AD Application. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password of the Azure AD application. (Optional)\n\n### Query Guidance\n\nIt is important to design your query to return 1 row. A good practice is to add `| limit 1` at the end of your query.\n\nThe only supported data types for your query result are `real`, `int` or `long`.\n\nBe careful with defining `pollingInterval` and using long-running queries. Make sure to test your query before using it.\n\n### Authentication Parameters\n\nYou can use the `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\nThe AD identity that will be used requires `DatabaseViewer` role to query metrics from the Data Explorer Cluster.\n\n💡You can use [this guide ](https://docs.microsoft.com/en-us/cli/azure/kusto/database?view=azure-cli-latest#az-kusto-database-add-principal) to assign your principal with the right access permissions through the Azure CLI.\n\n**Credential based authentication:**\n\n- `clientId` - Id of the Azure AD application. Use [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) guide to create your service principal.\n- `clientSecret` - Password of the Azure AD application.\n- `tenantId` - Id of the Azure AD tenant. Use [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) guide to retrieve your tenant id.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Examples\n\n### Use TriggerAuthentication with Azure AD Application\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secret\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: clientId\n      name: azure-data-explorer-secret # Required. Refers to the name of the secret\n      key: clientId\n    - parameter: clientSecret\n      name: azure-data-explorer-secret\n      key: clientSecret\n    - parameter: tenantId\n      name: azure-data-explorer-secret\n      key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure Pod Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-data-explorer-trigger-auth\nspec:\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n  kind: StatefulSet # Optional: Default: Deployment, Available Options: ReplicaSet Deployment, DaemonSet, StatefulSet\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-data-explorer\n    metadata:\n      databaseName: Weather\n      endpoint: https://keda.eastus.kusto.windows.net\n      query: |\n        StormEvents\n        | summarize StormCount = count() by State\n        | top 1 by StormCount desc\n    threshold: \"1000\"\n    authenticationRef:\n      name: azure-data-explorer-trigger-auth\n```\n\n### Use TriggerAuthentication with Azure AD Application through environment variables\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-data-explorer-secrets\ntype: Opaque\ndata:\n  clientId: <clientId> # Base64 encoded\n  clientSecret: <clientSecret> # Base64 encoded\n  tenantId: <tenantId> # Base64 encoded\n---\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: azure-data-explorer-example\nspec:\n  replicas: 0\n  selector:\n    matchLabels:\n      app: azure-data-explorer-example\n  template:\n    metadata:\n      labels:\n        app: azure-data-explorer-example\n    spec:\n      containers:\n      - name: example\n        image: nginx:1.16.1\n        env:\n        - name: AAD_APP_CLIENT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientId\n        - name: AAD_APP_SECRET\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: clientSecret\n        - name: AAD_APP_TENANT_ID\n          valueFrom:\n            secretKeyRef:\n              name: azure-data-explorer-secret\n              key: tenantId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-data-explorer-scaler\nspec:\n  scaleTargetRef:\n    name: azure-data-explorer-example\n  pollingInterval: 30\n  cooldownPeriod: 45\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  triggers:\n    - type: azure-data-explorer\n      metadata:\n        clientIdFromEnv: AAD_APP_CLIENT_ID\n        clientSecretFromEnv: AAD_APP_SECRET\n        tenantIdFromEnv: AAD_APP_TENANT_ID\n        databaseName: Weather\n        endpoint: https://keda.eastus.kusto.windows.net\n        query: |\n          StormEvents\n          | summarize StormCount = count() by State\n          | top 1 by StormCount desc\n        threshold: \"1000\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-event-hub.md",
    "content": "+++\ntitle = \"Azure Event Hubs\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Event Hubs.\"\ngo_file = \"azure_eventhub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-eventhub` trigger for Azure Event Hubs.\n\n```yaml\ntriggers:\n- type: azure-eventhub\n  metadata:\n    connectionFromEnv: EVENTHUB_CONNECTIONSTRING_ENV_NAME\n    storageConnectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    consumerGroup: $Default\n    unprocessedEventThreshold: '64'\n    activationUnprocessedEventThreshold: '10'\n    blobContainer: 'name_of_container'\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    endpointSuffix: servicebus.airgap.example\n    # Required when cloud = Private\n    storageEndpointSuffix: airgap.example\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n    # Required when cloud = Private.\n    eventHubResourceURL: https://eventhubs.airgap.example/\n    # Required when using pod identity authentication with blob storage\n    storageAccountName: 'name_of_account'\n```\n\n**Parameter list:**\n\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string appended with `EntityPath=<event_hub_name>`. If the connection string does not end with `EntityPath=<event_hub_name>`, then the parameters `eventHubName` / `eventHubNameFromEnv` must be used to provide the name of the Event Hub.\n- `storageConnectionFromEnv` - Name of the environment variable that provides connection string for Azure Storage Account to store checkpoint. As of now the Event Hub scaler only reads from Azure Blob Storage. (Only required when not using pod identity)\n- `consumerGroup` - Consumer group of Azure Event Hub consumer. (default: `$default`, Optional)\n- `unprocessedEventThreshold` - Average target value to trigger scaling actions. (Default: `64`, Optional)\n- `activationUnprocessedEventThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `blobContainer` - Container name to store checkpoint. This is needed for every `checkpointStrategy` except of `AzureFunction`. With Azure Functions the `blobContainer` is autogenerated and cannot be overridden.\n- `eventHubNamespace` - Name of the Event Hub namespace which has the Event Hub. (Optional)\n- `eventHubNamespaceFromEnv` - Name of the environment variable that provides the name of the Event Hub namespace, which has the Event Hub. (Optional)\n- `eventHubName` - Name of the Event Hub containing the messages. (Optional)\n- `eventHubNameFromEnv` - Name of the environment variable that provides the name of the Event Hub, containing the messages. (Optional)\n- `storageAccountName` - Account name for blob storage used for checkpoints. (Required when `storageConnectionFromEnv` is not specified. The storage account name is the first part in the hostname of a Blob Storage endpoint. E.g.: for `examplename.blob.core.windows.net` the account name is `examplename`.)\n- `checkpointStrategy` - configure the checkpoint behaviour of different Event Hub SDKs. (Values: `azureFunction`, `blobMetadata`, `goSdk`, default: `\"\"`, Optional)\n    - `azureFunction` - Suitable for Azure Functions & Azure WebJobs SDK. This is the default setting, when `blobcontainer` is not specified.\n    - `blobMetadata` - For all implementations that store checkpoint information on blob metadata such as current C#, Python, Java and JavaScript Event Hub SDKs.\n    - `goSdk` - For all implementations using the [Golang SDK](https://github.com/Azure/azure-event-hubs-go)'s checkpointing.\n    - `dapr` - Suitable for older Dapr pubsub and bindings\n      - Compatible Dapr versions:\n        - pubsub components: 1.6, 1.7, 1.8, 1.9\n        - bindings: 1.9\n      - For newer Dapr versions, use the `blobMetadata` strategy.\n      - For older Dapr versions, use the `goSdk` strategy.\n    - When no checkpoint strategy is specified, the Event Hub scaler will use backwards compatibility and able to scale older implementations of C#, Python or Java Event Hub SDKs. (see \"Legacy checkpointing\"). If this behaviour should be used, `blobContainer` is also required.\n- `cloud` - Name of the cloud environment that the Event Hub belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `endpointSuffix` - Service Bus endpoint suffix of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `servicebus.cloudapi.de` for `AzureGermanCloud`).\n- `storageEndpointSuffix` - Blob Storage endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `airgap.example`. Do not include the `blob` part of the endpoint.)\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.microsoftonline.de/` for `AzureGermanCloud`).\n- `eventHubResourceURL` - Event Hub resource URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://eventhubs.azure.net/` for known Azure Clouds).\n\n> 💡 Learn more about the checkpointing behaviour in this [section](#checkpointing-behaviour).\n\n> 💡 The Azure Storage connection string is not compatible with connection string created from a Shared Access Signature.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Event Hubs Namespace.\n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>;EntityPath=<hub-name>`.\n\n- `storageConnection` - Connection string for the Azure Storage Account used to store checkpoint information.\n\n> 💡 When providing `connection`, `EntityPath` is optional. If it is not provided, then `eventHubName` must be used to provide the name of the Azure Event Hub instance to use inside the namespace.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: nameOfTriggerAuth\n  namespace: default\nspec:\n  podIdentity:\n    provider: Azure | azure-workload\n```\n\nWhen you do so, the Event Hub scaler will depend on the existence of two configurations you have to provide: `eventHubNamespace` and `eventHubName`. You can also configure `storageAccountName` if you wish to use Azure AD Pod / Workload Identity to authenticate to Azure Blob Storage instead of a connection string.\n\n> 💡 When using Azure AD Pod Identity to authenticate the identity must have appropriate [RBAC role-assignments](https://docs.microsoft.com/azure/role-based-access-control/role-assignments-steps) for both Event Hub and Storage Account. Permissions covered by `Azure Event Hubs Data Receiver` and `Storage Blob Data Reader` are required.\n\n### Checkpointing Behaviour\n\nThe list of available checkpointing strategies can be found in the trigger specification [section](#trigger-specification). The way checkpoints are stored\nhas changed with updates to the EventHub SDKs.\n\n* **Legacy behaviour:** The older implementations are based on the `EventProcessorHost` client, which stores the checkpoint information as contents of\nthe storage blob. This is the default behaviour when no `checkpointStrategy` is specified.\nThis is applicable for the following scenarios:\n  - .NET applications using `Microsoft.Azure.EventHubs` NuGet package.\n  - Java applications using `azure-eventhubs-eph` package.\n  - Python applications using `azure-eventhub` package below v5.\n\n* **Current behaviour:** The newer implementations are based on the `EventProcessorClient`, which stores the checkpoint information as metadata on\nthe storage blob. This is the behaviour when `checkpointStrategy` is set to `blobMetadata`.\nThis is applicable for the following scenarios:\n  - .NET applications using `Azure.Messaging.EventHubs` NuGet package.\n  - Python applications using `azure-eventhub` v5.\n  - .NET Azure Functions using `Microsoft.Azure.WebJobs.Extensions.EventHubs` v5.\n  - Azure Functions in other languages using `Microsoft.Azure.Functions.ExtensionBundle` v3.\n\n> 💡 `blobContainer` name is required for applications following legacy behaviour.\n\n> 💡 Users should set `blobContainer` to `azure-webjobs-eventhub` for Azure Functions using `blobMetadata` as `checkpointStrategy`.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-eventhub-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureeventhub-function\n  triggers:\n  - type: azure-eventhub\n    metadata:\n      # Required\n      storageConnectionFromEnv: AzureWebJobsStorage\n      # Required if not using Pod Identity\n      connectionFromEnv: EventHub\n      # Required if using Pod Identity\n      eventHubNamespace: AzureEventHubNameSpace\n      eventHubName: NameOfTheEventHub\n# Optional\n      consumerGroup: $Default # default: $Default\n      unprocessedEventThreshold: '64' # default 64 events.\n      blobContainer: ehcontainer\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-log-analytics.md",
    "content": "+++\ntitle = \"Azure Log Analytics\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Log Analytics query result\"\ngo_file = \"azure_log_analytics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-log-analytics` trigger for Azure Log Analytics query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n  - type: azure-log-analytics\n    metadata:\n      tenantId: \"AZURE_AD_TENANT_ID\"\n      clientId: \"SERVICE_PRINCIPAL_CLIENT_ID\"\n      clientSecret: \"SERVICE_PRINCIPAL_PASSWORD\"\n      workspaceId: \"LOG_ANALYTICS_WORKSPACE_ID\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"10.7\"\n      activationThreshold: \"1.7\"\n      # Alternatively, you can use existing environment variables to read configuration from:\n      # See details in \"Parameter list\" section\n      workspaceIdFromEnv: LOG_ANALYTICS_WORKSPACE_ID_ENV_NAME # Optional. You can use this instead of `workspaceId` parameter.\n      clientIdFromEnv: SERVICE_PRINCIPAL_CLIENT_ID_ENV_NAME # Optional. You can use this instead of `clientId` parameter.\n      tenantIdFromEnv: AZURE_AD_TENANT_ID_ENV_NAME # Optional. You can use this instead of `tenantId` parameter.\n      clientSecretFromEnv: SERVICE_PRINCIPAL_PASSWORD_ENV_NAME # Optional. You can use this instead of `clientSecret` parameter.\n      # Optional (Default: AzurePublicCloud)\n      cloud: Private\n      # Required when cloud = Private\n      logAnalyticsResourceURL: https://api.loganalytics.airgap.io/\n      # Required when cloud = Private.\n      activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `tenantId` - Id of the Azure Active Directory tenant. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Id of the application from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Id of Log Analytics workspace. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n- `query` - Log Analytics [kusto](https://docs.microsoft.com/en-us/azure/azure-monitor/log-query/get-started-queries) query, JSON escaped. You can use [this](https://www.freeformatter.com/json-escape.html) tool to convert your query from Log Analytics query editor to JSON escaped string, and then review YAML specific escapes.\n- `threshold` - Value that is used as a threshold to calculate # of pods for scale target. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. (Optional, if not set KEDA will generate a name based on the workspaceId)\n- `cloud` - Name of the cloud environment that the Azure Log Analytics workspace belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `logAnalyticsResourceURL` - Log Analytics REST API URL of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://api.loganalytics.azure.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nThe authentication parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `tenantIdFromEnv` - An environmental variable name, that stores Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id. (Optional)\n- `clientIdFromEnv` - An environmental variable name, that stores Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal. (Optional)\n- `clientSecretFromEnv` - An environmental variable name, that stores password from your Azure AD Application/service principal. (Optional)\n- `workspaceIdFromEnv` - An environmental variable name, that stores your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id. (Optional)\n\n> 💡 **NOTE:** The workspaceID for Log Analytics is called the `customerId`;\n it's not the full `id`! the example `az` command below can be used.\n\n```sh\naz monitor log-analytics workspace list --query '[]. {ResourceGroup:resourceGroup,WorkspaceName:name,\"workspaceID (customerId)\":customerId}' -o table\n```\n\n### Query Guidance\n\nIt is important to design your query to return 1 table with 1 row. A good practice is to add \"| limit 1\" at the end of your query.\n\nScaler will take value from:\n\n- 1st cell as Metrics Value.\n- 2nd cell as Threshold (optional).\n\nYou can define threshold in trigger metadata, it will be used if your query results only 1 cell, that will be interpreted as metric value. Be aware, even if you have defined threshold in metadata, it can be overwritten by your query.\n\nData types of your query result should be: real, int or long. Other data types are not supported. Later, during runtime, your data will be converted to int64.\n\nBe careful with setting up \"pollingInterval\" and long-running queries. Test your query before.\n\nExample query to get `MetricValue` and `Threshold` based on CPU usage and limits, defined for the pod.\n\n```kusto\nlet AppName = \"web\";\nlet ClusterName = \"demo-cluster\";\nlet AvgDuration = ago(10m);\nlet ThresholdCoefficient = 0.8;\nPerf\n| where InstanceName contains AppName\n| where InstanceName contains ClusterName\n| where CounterName == \"cpuUsageNanoCores\"\n| where TimeGenerated > AvgDuration\n| extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n| summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n| join (Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuLimitNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n        | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n        on AppName\n| project MetricValue, Threshold = Limit * ThresholdCoefficient\n```\n\nExample result:\n\n![Azure Log Analytics query example](/img/azure-log-analytics-scaler-query-example.png)\n\n### Scaler Limitations\n\n- As it was mentioned before, you can define a threshold using query (2nd cell of query result will be interpret as threshold). Be aware! Threshold from query result will be set only once, during scaler creation. So, if your query will return different threshold values during runtime, they will not be propagated to Horizontal Pod Autoscaler target.\n\n### Authentication Parameters\n\n You can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials and resource identifiers.\n\n**Service Principal based authentication:**\n\n- `tenantId` - Azure Active Directory tenant id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/account?view=azure-cli-latest#az-account-show) link to retrieve your tenant id.\n- `clientId` - Application id from your Azure AD Application/service principal. Follow [this](https://docs.microsoft.com/en-us/cli/azure/ad/sp?view=azure-cli-latest) link to create your service principal.\n- `clientSecret` - Password from your Azure AD Application/service principal.\n- `workspaceId` - Your Log Analytics workspace id. Follow [this](https://docs.microsoft.com/en-us/cli/azure/monitor/log-analytics/workspace?view=azure-cli-latest#az-monitor-log-analytics-workspace-list) link to get your Log Analytics workspace id.\n\n**Managed identity based authentication:**\n\nYou can use managed identity to request access token for Log Analytics API. The advantage of this approach is that there is no need to store secrets in Kubernetes. Read [more](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity) about managed identities in Azure Kubernetes Service.\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n#### Service Principal based authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: kedaloganalytics\n  namespace: kedaloganalytics\n  labels:\n    app: kedaloganalytics\ntype: Opaque\ndata:\n  tenantId: \"QVpVUkVfQURfVEVOQU5UX0lE\" #Base64 encoded Azure Active Directory tenant id\n  clientId: \"U0VSVklDRV9QUklOQ0lQQUxfQ0xJRU5UX0lE\" #Base64 encoded Application id from your Azure AD Application/service principal\n  clientSecret: \"U0VSVklDRV9QUklOQ0lQQUxfUEFTU1dPUkQ=\" #Base64 encoded Password from your Azure AD Application/service principal\n  workspaceId: \"TE9HX0FOQUxZVElDU19XT1JLU1BBQ0VfSUQ=\" #Base64 encoded Log Analytics workspace id\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  secretTargetRef:\n    - parameter: tenantId\n      name: kedaloganalytics\n      key: tenantId\n    - parameter: clientId\n      name: kedaloganalytics\n      key: clientId\n    - parameter: clientSecret\n      name: kedaloganalytics\n      key: clientSecret\n    - parameter: workspaceId\n      name: kedaloganalytics\n      key: workspaceId\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n#### Managed identity based authentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: trigger-auth-kedaloganalytics\n  namespace: kedaloganalytics\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: kedaloganalytics-consumer-scaled-object\n  namespace: kedaloganalytics\n  labels:\n    deploymentName: kedaloganalytics-consumer\nspec:\n  scaleTargetRef:\n    kind: #Optional: Default: Deployment, Available Options: ReplicaSet, Deployment, DaemonSet, StatefulSet\n    name: kedaloganalytics-consumer\n  pollingInterval: 30\n  cooldownPeriod: 30\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-log-analytics\n    metadata:\n      workspaceId: \"81963c40-af2e-47cd-8e72-3002e08aa2af\"\n      query: |\n        let AppName = \"web\";\n        let ClusterName = \"demo-cluster\";\n        let AvgDuration = ago(10m);\n        let ThresholdCoefficient = 0.8;\n        Perf\n        | where InstanceName contains AppName\n        | where InstanceName contains ClusterName\n        | where CounterName == \"cpuUsageNanoCores\"\n        | where TimeGenerated > AvgDuration\n        | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n        | summarize MetricValue=round(avg(CounterValue)) by CounterName, AppName\n        | join (Perf\n                | where InstanceName contains AppName\n                | where InstanceName contains ClusterName\n                | where CounterName == \"cpuLimitNanoCores\"\n                | where TimeGenerated > AvgDuration\n                | extend AppName = substring(InstanceName, indexof((InstanceName), \"/\", 0, -1, 10) + 1)\n                | summarize arg_max(TimeGenerated, *) by AppName, CounterName\n                | project Limit = CounterValue, TimeGenerated, CounterPath, AppName)\n                on AppName\n        | project MetricValue, Threshold = Limit * ThresholdCoefficient\n      threshold: \"1900000000\"\n    authenticationRef:\n      name: trigger-auth-kedaloganalytics\n```\n\n### Guides\n\n#### Enabling managed identity authentication for Log Analytics scaler\n\nUse the following commands to create user defined identity, role assignment to Azure Log Analytics and deploy\\update KEDA:\n\n```sh\nexport SUBSCRIPTION_ID=\"<SubscriptionID>\"\nexport RESOURCE_GROUP=\"<AKSResourceGroup>\"\nexport CLUSTER_NAME=\"<AKSClusterName>\"\nexport CLUSTER_LOCATION=\"<AKSClusterLocation>\" # \"westeurope\", \"northeurope\"...\nexport IDENTITY_NAME=\"<SomeName>\" #Any name\nexport LOG_ANALYTICS_RESOURCE_ID=\"<LAResourceID>\"\n\n# Login to Azure, set subscription, get AKS credentials\naz login\naz account set -s \"${SUBSCRIPTION_ID}\"\naz aks get-credentials -n ${CLUSTER_NAME} -g ${RESOURCE_GROUP}\n\n# ------- Cluster preparation. Run this block only once for fresh cluster.\n# Clone repo and run initial role assignment\ngit clone https://github.com/Azure/aad-pod-identity.git\n./aad-pod-identity/hack/role-assignment.sh\n\n#Deploy aad-pod-identity using Helm 3\nhelm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts\nhelm repo update\nhelm install aad-pod-identity aad-pod-identity/aad-pod-identity --namespace=kube-system\n# -------------------------------------------------------------------------------------------\n\n#Create identity\naz identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}\nexport IDENTITY_CLIENT_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)\"\nexport IDENTITY_RESOURCE_ID=\"$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)\"\n\n#Assign reader permissions for your identity to Log Analytics workspace\n#WARNING: It can take some time while identity will be provisioned.\n#If you see an error: \"Principal SOME_ID does not exist in the directory SOME_ID\", just wait couple of minutes and then retry.\naz role assignment create --role \"Log Analytics Reader\" --assignee ${IDENTITY_CLIENT_ID} --scope ${LOG_ANALYTICS_RESOURCE_ID}\n\n# Allow cluster to control identity created earlier.\nID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)\"\nif [[ \"${ID:-}\" == \"msi\" ]]; then\n  ID=\"$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query identityProfile.kubeletidentity.clientId -otsv)\"\nfi\naz role assignment create --role \"Managed Identity Operator\" --assignee \"${ID}\" --scope \"${IDENTITY_RESOURCE_ID}\"\n\n# Create AzureIdentity and AzureIdentityBinding\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentity\nmetadata:\n  name: ${IDENTITY_NAME}\nspec:\n  type: 0\n  resourceID: ${IDENTITY_RESOURCE_ID}\n  clientID: ${IDENTITY_CLIENT_ID}\nEOF\n\ncat <<EOF | kubectl apply -f -\napiVersion: \"aadpodidentity.k8s.io/v1\"\nkind: AzureIdentityBinding\nmetadata:\n  name: ${IDENTITY_NAME}-binding\nspec:\n  azureIdentity: ${IDENTITY_NAME}\n  selector: ${IDENTITY_NAME}\nEOF\n\n# APPLY LABELS: OPTION 1\n#deploy KEDA using helm chart and specify aadPodIdentity label.\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace --set podIdentity.activeDirectory.identity=${IDENTITY_NAME}\n\n# APPLY LABELS: OPTION 2\n#Instead of redeploying KEDA, you can update existing deployment:\nkubectl patch deployment keda-operator -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\nkubectl patch deployment keda-metrics-apiserver -n keda --type json -p='[{\"op\": \"add\", \"path\": \"/spec/template/metadata/labels/aadpodidbinding\", \"value\": \"'${IDENTITY_NAME}'\"}]'\n```\n\n### Links\n\n- [AAD Pod Identity](https://github.com/Azure/aad-pod-identity)\n- [Use managed identities in Azure Kubernetes Service](https://docs.microsoft.com/en-us/azure/aks/use-managed-identity)\n- [Azure Pod Identity on keda.sh](https://keda.sh/docs/2.0/concepts/authentication/#azure-pod-identity)\n- [Best practices for authentication and authorization in Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-identity)\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-monitor.md",
    "content": "+++\ntitle = \"Azure Monitor\"\navailability = \"v1.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Monitor metrics.\"\ngo_file = \"azure_monitor_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-monitor` trigger that scales based on an Azure Monitor metric.\n\n```yaml\ntriggers:\n- type: azure-monitor\n  metadata:\n    resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n    tenantId: xxx-xxx-xxx-xxx-xxx\n    subscriptionId: yyy-yyy-yyy-yyy-yyy\n    resourceGroupName: azureMonitor\n    metricName: kube_pod_status_ready\n    metricFilter: namespace eq 'default'\n    metricAggregationInterval: \"0:1:0\"\n    targetValue: \"0.5\"\n    activationTargetValue: \"3.5\"\n    activeDirectoryClientId: <client id value> # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientIdFromEnv: CLIENT_ID_ENV_NAME # Optional, can use TriggerAuthentication as well\n    activeDirectoryClientPasswordFromEnv: CLIENT_PASSWORD_ENV_NAME # Optional, can use TriggerAuthentication as well\n    # Optional (Default: AzurePublicCloud)\n    cloud: Private\n    # Required when cloud = Private\n    azureResourceManagerEndpoint: https://management.azure.airgap.com/\n    # Required when cloud = Private.\n    activeDirectoryEndpoint: https://login.airgap.example/\n```\n\n**Parameter list:**\n\n- `resourceURI` - Shortened URI to the Azure resource with format `\"<resourceProviderNamespace>/<resourceType>/<resourceName>\"`.\n- `tenantId` - Id of the tenant that contains the Azure resource. This is used for authentication.\n- `subscriptionId` - Id of Azure subscription that contains the Azure resource. This is used for determining the full resource URI.\n- `resourceGroupName` - Name of the resource group for the Azure resource.\n- `metricName` - Name of the metric to query.\n  - Azure metrics are available as a list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n  - Custom metric name when querying Azure Monitor [custom metrics](https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/metrics-custom-overview).\n- `metricNamespace` - Name of the metric namespace. Required when `metricName` is a custom metric.\n- `targetValue` - Target value to trigger scaling actions. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricAggregationType` - Aggregation method of the Azure Monitor metric. Options include `Average`, `Total`, `Maximum` with a full list in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported).\n- `metricFilter` - Name of the filter to be more specific by using dimensions listed in the [official documentation](https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported). (Optional)\n- `metricAggregationInterval` - Collection time of the metric in format `\"hh:mm:ss\"` (Default: `\"0:5:0\"`, Optional)\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions. (Optional)\n- `activeDirectoryClientPasswordFromEnv` - Name of the environment variable that contains the active directory client password. (Optional)\n- `cloud` - Name of the cloud environment that the Azure resource belongs to. (Values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureGermanCloud`, `AzureChinaCloud`, `Private`, Default: `AzurePublicCloud`, Optional)\n- `azureResourceManagerEndpoint` - Azure Resource Manager endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://management.chinacloudapi.cn/` for `AzureChinaCloud`).\n- `activeDirectoryEndpoint` - Active Directory endpoint of the cloud environment. (Required when `cloud` is set to `Private`, e.g. `https://login.chinacloudapi.cn/` for `AzureChinaCloud`).\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `activeDirectoryClientIdFromEnv` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions, similar to `activeDirectoryClientId`, but reads it from an environment variable on the scale target. (Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication by providing a set of Azure Active Directory credentials or by using pod identity.\n\n**Credential based authentication:**\n\n- `activeDirectoryClientId` - Id of the Active Directory application which requires at least `Monitoring Reader` permissions.\n- `activeDirectoryClientPassword` - Password of the Active Directory application.\n\nThe user will need access to read data from the Azure resource.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: azure-monitor-secrets\ndata:\n  activeDirectoryClientId: <clientId>\n  activeDirectoryClientPassword: <clientPassword>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-monitor-trigger-auth\nspec:\n  secretTargetRef:\n    - parameter: activeDirectoryClientId\n      name: azure-monitor-secrets\n      key: activeDirectoryClientId\n    - parameter: activeDirectoryClientPassword\n      name: azure-monitor-secrets\n      key: activeDirectoryClientPassword\n  # or Pod Identity, kind: Secret is not required in case of pod Identity\n  podIdentity:\n      provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-monitor-scaler\nspec:\n  scaleTargetRef:\n    name: azure-monitor-example\n  minReplicaCount: 1\n  maxReplicaCount: 10\n  triggers:\n  - type: azure-monitor\n    metadata:\n      resourceURI: Microsoft.ContainerService/managedClusters/azureMonitorCluster\n      tenantId: xxx-xxx-xxx-xxx-xxx\n      subscriptionId: yyy-yyy-yyy-yyy-yyy\n      resourceGroupName: azureMonitor\n      metricName: pod_custom_metric\n      metricNamespace: pod_custom_metrics_namespace # required when monitoring custom metrics\n      metricFilter: namespace eq 'default'\n      metricAggregationInterval: \"0:1:0\"\n      metricAggregationType: Average\n      targetValue: \"1\"\n    authenticationRef:\n      name: azure-monitor-trigger-auth\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-pipelines.md",
    "content": "+++\ntitle = \"Azure Pipelines\"\navailability = \"v2.3+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on agent pool queues for Azure Pipelines.\"\ngo_file = \"azure_pipelines_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-pipelines` trigger for Azure Pipelines. It scales based on the amount of pipeline runs pending in a given agent pool.\n\n```yaml\ntriggers:\n  - type: azure-pipelines\n    metadata:\n      # Optional: Name of the pool in Azure DevOps\n      poolName: \"{agentPoolName}\"\n      # Optional: Learn more in 'How to determine your pool ID'\n      poolID: \"{agentPoolId}\"\n      # Optional: Azure DevOps organization URL, can use TriggerAuthentication as well\n      organizationURLFromEnv: \"AZP_URL\"\n      # Optional: Azure DevOps Personal Access Token, can use TriggerAuthentication as well\n      personalAccessTokenFromEnv: \"AZP_TOKEN\"\n      # Optional: Target queue length\n      targetPipelinesQueueLength: \"1\" # Default 1\n      activationTargetPipelinesQueueLength: \"5\" # Default 0\n      # Optional: Parent template to read demands from\n      parent: \"{parent ADO agent name}\"\n      # Optional: Demands string to read demands from ScaledObject\n      demands: \"{demands}\"\n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n**Parameter list:**\n\n- `poolName` - Name of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `poolID` - Id of the pool. (Optional, either `poolID` or `poolName` must be configured)\n- `organizationURLFromEnv` - Name of the environment variable your deployment uses to get the URL for your Azure DevOps organization.\n- `personalAccessTokenFromEnv` - Name of the environment variable that provides the personal access token (PAT) for Azure DevOps. Learn more about how to create one [in the official docs](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).\n- `targetPipelinesQueueLength` - Target value for the amount of pending jobs in the queue to scale on. (Default: `1`, Optional)\n  - Example - If one pod can handle 10 jobs, set the queue length target to 10. If the actual number of jobs in the queue is 30, the scaler scales to 3 pods.\n- `activationTargetPipelinesQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `parent` - Put the name of the ADO agent that matched the ScaledObject. e.g. mavenagent-scaledobject may have an initial deployment called \"mavenagent-keda-template\"; this is the deployment that is made offline. This name is provided to the initial deployment as the environment variable \"AZP_NAME\"\n- `demands` - Put the demands string that was provided to the ScaledObject. This MUST be a subset of the actual capability list the agent has. e.g. `maven,docker`\n\n> 💡 **NOTE:** You can either use `poolID` or `poolName`. If both are specified, then `poolName` will be used.\n\n### Authentication Parameters\n\nAs an alternative to using environment variables, you can authenticate with Azure Devops using a Personal Access Token via `TriggerAuthentication` configuration.\n\n**Personal Access Token Authentication:**\n\n- `organizationURL` - The URL of the Azure DevOps organization.\n- `personalAccessToken` - The Personal Access Token (PAT) for Azure DevOps.\n\n### How to determine your pool ID\n\nThere are several ways to get the `poolID`. The easiest could be using `az cli` to get it using the command `az pipelines pool list --pool-name {agentPoolName} --organization {organizationURL} --query [0].id`.\n\nIt is also possible to get the pool ID using the UI by browsing to the agent pool from the organization (Organization settings -> Agent pools -> `{agentPoolName}`) and getting it from the URL.\nThe URL should be similar to `https://dev.azure.com/{organization}/_settings/agentpools?poolId={poolID}&view=jobs`\n\n> Careful - You should determine this on an organization-level, not project-level. Otherwise, you might get an incorrect id.\n\nFinally, it is also possible get the pool ID from the response of a HTTP request by calling the `https://dev.azure.com/{organizationName}/_apis/distributedtask/pools?poolname={agentPoolName}` endpoint in the key `value[0].id`.\n\n### Supporting demands in agents\n\nBy default, if you do not wish to use demands in your agent scaler then it will scale based simply on the pool's queue length.\n\nDemands (Capabilities) are useful when you have multiple agents with different capabilities existing within the same pool,\nfor instance in a kube cluster you may have an agent supporting dotnet5, dotnet6, java or maven;\nparticularly these would be exclusive agents where jobs would fail if run on the wrong agent. This is Microsoft's demands feature.\n\n- **Using Parent:** Azure DevOps is able to determine which agents can match any job it is waiting for. If you specify a parent template then KEDA will further interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload fulfill the request. The parent template that is generally offline must stay in the Pool's Agent list.\n\n- **Using demands:** KEDA will determine which agents can fulfill the job based on the demands provided. The demands are provided as a comma-separated list and must be a subset of the actual capabilities of the agent. (For example `maven,java,make`. Note: `Agent.Version` is ignored)\n\nMicrosoft's documentation: [https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/demands?view=azure-devops&tabs=yaml)\n\nPlease note that the parent template feature is exclusive to KEDA and not Microsoft and is another way of supporting demands.\n\nIf you wish to use demands in your agent scaler then you can do so by adding the following to your pipeline:\n\n```yaml\n    pool:\n      - name: \"{agentPoolName}\"\n        demands: \n          - example-demands\n          - another-demand -equals /bin/executable\n```\n\nThen, you can use the `demands` parameter to specify the demands that your agent supports or the `parent` parameter to link a template that matches you scaled object.\n\nKEDA will use the following evaluation order:\n1) If neither parent nor demands are defined in the scaling definition, it will scale the workload to fulfill the job.\n2) If `parent` is set,  KEDA will interrogate the job request to determine if the parent is able to fulfill the job. If the parent is able to complete the job it scales the workload to fulfill the request.\n3) Finally, if the demands are set in the scaling definition then KEDA will determine which agents can fulfill the job based on the demands provided.\n\n> Note: If more than one scaling definition is able to fulfill the demands of the job then they will both spin up an agent.\n\n#### How it works under the hood\n\nAzure DevOps has a Job Request API with returns a list of all jobs, and the agent that they are assigned to, or could potentially be assigned to. This is an undocumented Microsoft API which is available on `https://dev.azure.com/<organisation>/_apis/distributedtask/pools/<poolid>/jobrequests`.\n\nKEDA will interpret this request to find any matching template from the defined parent in the scaling definition, or any agent that can satisfy the demands specified in the scaling definition.\n\nOnce it finds it, it will scale the workload that matched the definition and Azure DevOps will assign it to that agent.\n\n### Configuring the agent container\n\nMicrosoft self-hosted docker agent documentation: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux\n\nPlease use the script in Step 5 as the entrypoint for your agent container.\n\nYou will need to change this section of the shell script so that the agent will terminate and cleanup itself when the job is complete by using the `--once` switch.\nThe if statement for cleanup is only required if you are using the auto-deployment parent template method.\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\ntrap 'cleanup; exit 0' EXIT\ntrap 'cleanup; exit 130' INT\ntrap 'cleanup; exit 143' TERM\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" & wait $!\n```\n\nto\n\n\n```\nprint_header \"4. Running Azure Pipelines agent...\"\n\nif ! grep -q \"template\" <<< \"$AZP_AGENT_NAME\"; then\n  echo \"Cleanup Traps Enabled\"\n\n  trap 'cleanup; exit 0' EXIT\n  trap 'cleanup; exit 130' INT\n  trap 'cleanup; exit 143' TERM\n\nfi\n\nchmod +x ./run-docker.sh\n\n# To be aware of TERM and INT signals call run.sh\n# Running it with the --once flag at the end will shut down the agent after the build is executed\n./run-docker.sh \"$@\" --once & wait $!\n```\n\n### Example for ScaledObject\n\n```yaml\napiVersion: v1\nkind: Secret\ntype: Opaque\nmetadata:\n  name: pipeline-auth\ndata:\n  personalAccessToken: <encoded personalAccessToken>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: pipeline-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: personalAccessToken\n      name: pipeline-auth\n      key: personalAccessToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-pipelines-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azdevops-deployment\n  minReplicaCount: 1\n  maxReplicaCount: 5\n  triggers:\n  - type: azure-pipelines\n    metadata:\n      poolID: \"1\"\n      organizationURLFromEnv: \"AZP_URL\"\n      parent: \"example-keda-template\"\n      demands: \"maven,docker\"      \n    authenticationRef:\n     name: pipeline-trigger-auth\n```\n\n###Example for Parent Deployment or StatefulSet\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: agent\nspec:\n  replicas: 1\n  selector:\n    matchLabels:\n      app: agent\n  spec:\n    containers:\n      - name: agent\n        image: [SAME AS SCALED JOB]\n        envFrom:\n          - secretRef:\n              name: ado-pat-tokens\n        env:\n          - name: AZP_AGENT_NAME\n            value: example-keda-template # Matches Scaled Job Parent\n          \n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-service-bus.md",
    "content": "+++\ntitle = \"Azure Service Bus\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Service Bus Queues or Topics.\"\navailability = \"v1.0+\"\ngo_file = \"azure_servicebus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-servicebus` trigger for Azure Service Bus Queue or Topic.\n\n> ⚠️ **WARNING:** KEDA is not in charge of managing entities. If the queue, topic or subscription does not exist, it will not create them automatically.\n\n```yaml\ntriggers:\n- type: azure-servicebus\n  metadata:\n    # Required: queueName OR topicName and subscriptionName\n    queueName: functions-sbqueue\n    # or\n    topicName: functions-sbtopic\n    subscriptionName: sbtopic-sub1\n    # Optional, required when pod identity is used\n    namespace: service-bus-namespace\n    # Optional, can use TriggerAuthentication as well\n    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME\n    # Optional\n    messageCount: \"5\" # Optional. Count of messages to trigger scaling on. Default: 5 messages\n    activationMessageCount: \"2\"\n    cloud: Private # Optional. Default: AzurePublicCloud\n    endpointSuffix: servicebus.airgap.example # Required when cloud=Private\n```\n\n**Parameter list:**\n\n- `messageCount` - Amount of active messages in your Azure Service Bus queue or topic to scale on.\n- `activationMessageCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `queueName` - Name of the Azure Service Bus queue to scale on. (Optional)\n- `topicName` - Name of the Azure Service Bus topic to scale on. (Optional)\n- `subscriptionName` - Name of the Azure Service Bus queue to scale on. (Optional*, Required when `topicName` is specified)\n- `namespace` - Name of the Azure Service Bus namespace that contains your queue or topic. (Optional*, Required when pod identity is used)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string of the Azure Service Bus namespace. (Optional)\n- `useRegex` - Provides indication whether or not a regex is used in the `queueName` or `subscriptionName` parameters. (Values: `true`, `false`, Default: `false`, Optional)\n- `operation` - Defines how to compute the number of messages when `useRegex` is set to `true`. (Values: `sum`, `max`, or `avg`, Default: `sum`, Optional).\n- `cloud` - Name of the cloud environment that the service bus belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the service bus endpoint suffix of the cloud environment that the service bus belongs to, e.g. `servicebus.usgovcloudapi.net` for `AzureUSGovernmentCloud`.\n\n> 💡 **NOTE:** Service Bus Shared Access Policy needs to be of type `Manage`. Manage access is required for KEDA to be able to get metrics from Service Bus.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for the Azure Service Bus Namespace. \n  \n  The following formats are supported.\n  \n  - With **SharedAccessKey** - \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessKeyName=<key name>;SharedAccessKey=<key value>`\n  - With **SharedAccessSignature** -  \n    `Endpoint=sb://<sb>.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>`  \n    Refer to this [page](https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-sas) for more information\n    on using Shared Access Signatures.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\nHere is an example of how to use managed identity:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-servicebus-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-servicebus-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azure-servicebus-queue-function\n  triggers:\n  - type: azure-servicebus\n    metadata:\n      # Required: queueName OR topicName and subscriptionName\n      queueName: functions-sbqueue\n      # or\n      topicName: functions-sbtopic\n      subscriptionName: sbtopic-sub1\n      # Required: Define what Azure Service Bus to authenticate to with Managed Identity\n      namespace: service-bus-namespace\n      # Optional\n      messageCount: \"5\" # default 5\n      cloud: AzureGermanCloud # Optional. Default: AzurePublicCloud\n    authenticationRef:\n        name: azure-servicebus-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-storage-blob.md",
    "content": "+++\ntitle = \"Azure Blob Storage\"\navailability = \"v1.1+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on the count of blobs in a given Azure Blob Storage container.\"\nnotice = \"As of now, this Azure Blob Storage scaler scales based on the count of the blobs in a container as opposed to the Azure Functions behavior where code is only triggered on new blobs.\"\ngo_file = \"azure_blob_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-blob` trigger for Azure Blob Storage. It scales based on the count of blobs in a given blob storage container and assumes the worker is responsible for clearing the container by deleting/moving the blobs once the blob processing completed.\n\n```yaml\ntriggers:\n- type: azure-blob\n  metadata:\n    blobContainerName: functions-blob\n    blobCount: '5'\n    activationBlobCount: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    blobPrefix: myprefix\n    blobDelimiter: /example\n    cloud: Private\n    endpointSuffix: blob.core.airgap.example # Required when cloud=Private\n    recursive: false\n    globPattern: glob-pattern\n```\n\n**Parameter list:**\n\n- `blobContainerName` - Name of container in an Azure Storage account.\n- `blobCount` - Average target value to trigger scaling actions. (Default: `5`, Optional)\n- `activationBlobCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the container belongs to.\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `/`, Optional)\n- `cloud` - Name of the cloud environment that the blob belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n- `recursive` - Indicates whether or not blobs should be counted recursively. (Values: `true`, `false`, Default: `false`, Optional, Equivalent to setting `blobDelimiter` as `\"\"`)\n- `globPattern` - Glob pattern for blob names. The scaler will count all blobs whose names match the pattern\nas metric value. (Default: `\"\"`, Optional, The `blobPrefix`, `blobDelimiter` and `recursive` parameters are ignored when this is specified.)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage blob endpoint suffix of the cloud environment that the blob belongs to, e.g. `blob.core.cloudapi.de` for `AzureGermanCloud`.\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on the trigger index and `blobContainerName`. For example: **s0-azure-blob-blobContainerName**. The value will be prefixed with `s{triggerIndex}-azure-blob-`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod Identity Authentication**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n- `accountName` - Name of the Azure Storage Account.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-blob-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-blob-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azureblob-function\n  triggers:\n  - type: azure-blob\n    metadata:\n      # Required\n      blobContainerName: functionsblob\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional, connection OR authenticationRef that defines the connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      blobCount: \"5\" # default 5\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"/\"\n      # Optional, default: AzurePublicCloud\n      cloud: AzureChinaCloud\n    authenticationRef:\n        name: azure-blob-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/azure-storage-queue.md",
    "content": "+++\ntitle = \"Azure Storage Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Azure Storage Queues.\"\ngo_file = \"azure_queue_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `azure-queue` trigger for Azure Storage Queue.\n\n```yaml\ntriggers:\n- type: azure-queue\n  metadata:\n    queueName: orders\n    queueLength: '5'\n    activationQueueLength: '50'\n    connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME\n    accountName: storage-account-name\n    cloud: AzureUSGovernmentCloud\n```\n\n**Parameter list:**\n\n- `queueName` - Name of the queue.\n- `queueLength` - Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. (Default: `5`, Optional)\n- `activationQueueLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionFromEnv` - Name of the environment variable your deployment uses to get the connection string.\n- `accountName` - Name of the storage account that the queue belongs to.\n- `cloud` - Name of the cloud environment that the queue belongs to. Must be a known Azure cloud environment, or `Private` for Azure Stack Hub or Air Gapped clouds. (valid values: `AzurePublicCloud`, `AzureUSGovernmentCloud`, `AzureChinaCloud`, `AzureGermanCloud`, `Private`; default: `AzurePublicCloud`)\n\nWhen `cloud` is set to `Private`, the `endpointSuffix` parameter is required. Otherwise, it is automatically generated based on the cloud environment. `endpointSuffix` represents the storage queue endpoint suffix of the cloud environment that the queue belongs to, e.g. `queue.core.windows.net` for `AzurePublicCloud`.\n\n### Authentication Parameters\n\nYou can authenticate by using pod identity or connection string authentication.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for Azure Storage Account.\n\n**Pod identity based authentication:**\n\n[Azure AD Pod Identity](https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity) or [Azure AD Workload Identity](https://azure.github.io/azure-workload-identity/docs/) providers can be used.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: azure-queue-auth\nspec:\n  podIdentity:\n    provider: azure | azure-workload\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: azure-queue-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: azurequeue-function\n  triggers:\n  - type: azure-queue\n    metadata:\n      # Required\n      queueName: functionsqueue\n      # Optional, required when pod identity is used\n      accountName: storage-account-name\n      # Optional: connection OR authenticationRef that defines connection\n      connectionFromEnv: STORAGE_CONNECTIONSTRING_ENV_NAME # Default: AzureWebJobsStorage. Reference to a connection string in deployment\n      # or authenticationRef as defined below\n      #\n      # Optional\n      queueLength: \"5\" # default 5\n      cloud: Private\n      endpointSuffix: queue.local.azurestack.external # Required when cloud=Private\n    authenticationRef:\n        name: azure-queue-auth # authenticationRef would need either podIdentity or define a connection parameter\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/cassandra.md",
    "content": "+++\ntitle = \"Cassandra\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Cassandra query results.\"\ngo_file = \"cassandra_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cassandra` trigger that scales based on the outputs of a Cassandra query.\n\n```yaml\ntriggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      keyspace: \"test_keyspace\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      activationTargetQueryValue: \"10\"\n      metricName: \"test_keyspace\"\n```\n\n**Parameter list:**\n\n- `username` - The username credential for connecting to the Cassandra instance.\n- `port` - The port number of the Cassandra instance. (Optional, Can be set either here or in `clusterIPAddress`)\n- `clusterIPAddress` - The IP address or the host name of the Cassandra instance.\n- `consistency` - Configuration for a session or per individual read operation. (Values: `LOCAL_ONE`, `LOCAL_QUORUM`, `EACH_QUORUM`, `LOCAL_SERIAL`, `ONE`, `TWO`, `THREE`, `QUORUM`, `SERIAL`, `ALL`, Default: `ONE`, Optional)\n- `protocolVersion` - CQL Binary Protocol. (Default: `4`, Optional)\n- `keyspace` - The name of the keyspace used in Cassandra.\n- `query` - A Cassandra query that should return single numeric value.\n- `targetQueryValue` - The threshold value that is provided by the user and used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA).\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `metricName` - Name to assign to the metric. (Default: `s<X>-cassandra-<KEYSPACE>`, Optional, In case of `metricName` is specified, it will be used to generate the `metricName` like this: `s<X>-cassandra-<METRICNAME>`, where `<X>` is the index of the trigger in a ScaledObject)\n\n### Authentication Parameters\n\nYou can authenticate by using a password via `TriggerAuthentication` configuration.\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Cassandra instance.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: cassandra-secrets\ntype: Opaque\ndata:\n  cassandra_password: CASSANDRA_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-cassandra-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: cassandra-secrets\n    key: cassandra_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cassandra-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: cassandra\n    metadata:\n      username: \"cassandra\"\n      port: \"9042\"\n      clusterIPAddress: \"cassandra.default\"\n      consistency: \"Quorum\"\n      protocolVersion: \"4\"\n      query: \"SELECT COUNT(*) FROM test_keyspace.test_table;\"\n      targetQueryValue: \"1\"\n      metricName: \"test_keyspace\"\n    authenticationRef:\n      name: keda-trigger-auth-cassandra-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/couchdb.md",
    "content": "+++\ntitle = \"CouchDB\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on CouchDB query results.\"\ngo_file = \"couchdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `couchdb` trigger that scales based on the outputs of a CouchDB query.\n\n```yaml\ntriggers:\n- type: couchdb\n  metadata:\n    connectionStringFromEnv: \"CONNECTION_STRING\"\n    host: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"   \n    port: \"5984\" \n    dbName: \"animals\" \n    queryValue: \"1\" \n    query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n    activationQueryValue: \"1\"\n```\n\n**Parameter list:**\n\n- `host` - The hostname for connecting to the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `dbName` - Name of the database. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `queryValue` - A threshold that will define when scaling should occur. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `port` - The port number of the CouchDB service. (Optional, Required if `connectionString` and `connectionStringFromEnv` is not set)\n- `query` - A CouchDB query that should return single numeric value. (Optional)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `connectionStringFromEnv` - Environment variable from workload with the connection string. (Optional, Required if `connectionString` and connection parameters aren't set)\n\n### Authentication Parameters\n\nYou can authenticate by using a username and password via `TriggerAuthentication` configuration.\n\n**ConnectionString:**\n\n- `connectionString` - Connection string for CouchDB database. (Optional, Required if `connectionStringFromEnv` and connection parameters aren't set)\n\n**Password Authentication:**\n\n- `password` - Password for configured user to login to the Couchdb instance.\n- `username` - Username for configured user to login to the Couchdb instance.\n\n### Example\n\nHere is an example of a couchdb scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: couchdb-secrets\ndata:\n  username: COUCHDB_USERNAME\n  password: COUCHDB_PASSWORD\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-couchdb-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: couchdb-secrets\n    key: password\n  - parameter: username\n    name: couchdb-secrets\n    key: username\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: couchdb-scaledobject\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  triggers:\n  - type: couchdb\n    metadata:\n      hostname: \"test-release-svc-couchdb.couchdb-test-ns.svc.cluster.local\"\n      port: \"5984\"\n      dbName: \"animals\"\n      queryValue: \"1\"\n      query: '{ \"selector\": { \"feet\": { \"$gt\": 0 } }, \"fields\": [\"_id\", \"feet\", \"greeting\"] }'\n      activationQueryValue: \"1\"\n      metricName: \"global-metric\"\n    authenticationRef:\n      name: keda-trigger-auth-couchdb-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/cpu.md",
    "content": "+++\ntitle = \"CPU\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on cpu metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `cpu` trigger that scales based on cpu metrics.\n\n```yaml\ntriggers:\n- type: cpu\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its CPU, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets CPU utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets CPU utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cpu-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: cpu\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/cron.md",
    "content": "+++\ntitle = \"Cron\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a cron schedule.\"\ngo_file = \"cron_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `cron` trigger that scales workloads in/out based on a cron Schedule.\n\n```yaml\ntriggers:\n- type: cron\n  metadata:\n    # Required\n    timezone: Asia/Kolkata  # The acceptable values would be a value from the IANA Time Zone Database.\n    start: 0 6 * * *        # At 6:00 AM\n    end: 0 20 * * *         # At 8:00 PM\n    desiredReplicas: \"10\"\n```\n\n**Parameter list:**\n\n- `timezone` - One of the acceptable values from the IANA Time Zone Database. The list of timezones can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).\n- `start` - Cron expression indicating the start of the cron schedule.\n- `end` - Cron expression indicating the end of the cron schedule.\n- `desiredReplicas` - Number of replicas to which the resource has to be scaled **between the start and end** of the cron schedule.\n\n> 💡 **Note:** `start`/`end` support [\"Linux format cron\"](https://en.wikipedia.org/wiki/Cron) (Minute Hour Dom Month Dow).\n\n> **Notice:**\n> **Start and end should not be same.**\n>\n> For example, the following schedule is not valid:\n> ```yaml\n> start: 0 6 * * *        # At 6:00 AM\n> end: 0 6 * * *          # also at 6:00 AM\n>```\n\n### How does it work?\n\nThe CRON scaler allows you to define a time range in which you want to scale your workloads out/in.\n\nWhen the time window starts, it will scale from the minimum number of replicas to the desired number of replicas based on your configuration.\n\n![](/img/scalers/cron/how-it-works.png)\n\nWhat the CRON scaler does **not** do, is scale your workloads based on a recurring schedule.\n\n### Scale to 0 during off hours\n\nIf you want to scale you deployment to 0 outside office hours / working hours,\nyou need to set `minReplicaCount: 0` in the ScaledObject, and increase the\nreplicas during work hours. That way the Deployment will be scaled to 0 outside\nthat time window. By default the ScaledObject `cooldownPeriod` is 5 minutes, so the actual\nscaling down will happen 5 minutes after the cron schedule `end` parameter.\n\nIt's almost always an error to try to do the other way\naround, i.e. set `desiredReplicas: 0` in the cron trigger.\n\n> 💡 **NOTE**: As the HPA Controller will evaluate all the metrics at once and will take the one which requires more instances (`max(metrics)`), the value set for `desiredReplicas` technically acts as a \"dynamic\" minimum replicas. For example, if you have other trigger like CPU, during the time between `start` and `end` you will have AT LEAST `desiredReplicas` because of that `max(metrics)`.\n\n\n> Once a deployment is scaled down to 0 replicas, the checks relying on pod-related metrics are **ignored**, given that no pods are currently running and these metrics are therefore impossible to retrieve. For this reason, **pod-related metrics are also ignored** for scaling to zero and this process is done only considering external metrics.\n\n#### TL;DR\n- Set `minReplicaCount` to 0\n- Create your `cron` trigger: define `start`, `end` and `timezone`, and set `desiredReplicas` to the previous value of `minReplicaCount`\n- If you also want to use other criteria to scale your deployment, just add other triggers to your `ScaledObject`\n\n\n#### Example: fixed number of replicas (scale up to 10 replicas from 6AM to 8PM and scale down to 0 replicas otherwise)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"10\"\n```\n\n#### Example: dynamic number of replicas (0 during night, between 1 and 4 during day)\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: cron-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  minReplicaCount: 0\n  maxReplicaCount: 4\n  cooldownPeriod: 300\n  triggers:\n    - type: cron\n      metadata:\n        timezone: Asia/Kolkata\n        start: 0 6 * * *\n        end: 0 20 * * *\n        desiredReplicas: \"1\"\n    - type: cpu\n      metricType: Utilization\n      metadata:\n        value: \"80\"\n```\nThe deployment will scale to 0 between 20:00 and 06:00, and will have between 1 and 4 replicas between 06:00 and 20:00.\n"
  },
  {
    "path": "content/docs/2.9/scalers/datadog.md",
    "content": "+++\ntitle = \"Datadog\"\navailability = \"v2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Datadog.\"\ngo_file = \"datadog_scaler\"\n+++\n\n> 💡 **NOTE:** Take into account [API Datadog endpoints rate\nlimits](https://docs.datadoghq.com/api/latest/rate-limits/) when defining\npolling interval. For more detailed information about polling intervals check\n[the Polling intervals and Datadog rate limiting\nsection](#polling-intervals-and-datadog-rate-limiting).\n\n### Trigger Specification\n\nThis specification describes the `datadog` trigger that scales based on a Datadog metric.\n\n```yaml\ntriggers:\n- type: datadog\n  metricType: Value\n  metadata:\n    query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n    queryValue: \"7.75\"\n    activationQueryValue: \"1.1\"\n    queryAggregator: \"max\"\n    type: \"global\" # Deprecated in favor of trigger.metricType\n    age: \"120\"\n    timeWindowOffset: \"30\"\n    lastAvailablePointOffset: \"1\"\n    metricUnavailableValue: \"1.5\"\n```\n\n**Parameter list:**\n\n- `query` - The Datadog query to run.\n- `queryValue` - Value to reach to start scaling (This value can be a float).\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryAggregator` - When `query` is multiple queries, comma-seperated, this sets how to aggregate the multiple results. (Values: `max`, `average`, Required only when `query` contains multiple queries)\n- `type` - Whether to start scaling based on the value or the average between pods. (Values: `average`, `global`, Default:`average`, Optional)\n- `age`: The time window (in seconds) to retrieve metrics from Datadog. (Default: `90`, Optional)\n- `timeWindowOffset`: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust `timeWindowOffset` if you encounter this issue. (Default: `0`, Optional)\n- `lastAvailablePointOffset`: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate [because of the implicit rollup function](https://docs.datadoghq.com/dashboards/functions/rollup/#rollup-interval-enforced-vs-custom), try to adjust to `1` if you encounter this issue. (Default: `0`, Optional)\n- `metricUnavailableValue`: The value of the metric to return to the HPA if Datadog doesn't find a metric value for the specified time window. If not set, an error will be returned to the HPA, which will log a warning. (Optional, This value can be a float)\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Authentication\n\nDatadog requires both an API key and an APP key to retrieve metrics from your account.\n\nYou should use `TriggerAuthentication` CRD to configure the authentication:\n\n**Parameter list:**\n\n- `apiKey` - Datadog API key.\n- `appKey` - Datadog APP key.\n- `datadogSite` - Datadog site where to get the metrics from. This is commonly referred as DD_SITE in Datadog documentation. (Default: `datadoghq.com`, Optional)\n\n### Example\n\nThe example below uses the default KEDA polling interval (30 seconds). Take into\naccount that [API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/) and reducing the\npolling interval can accelerate reaching it. If your account has reached its\nrate limit, a relevant error will be logged in KEDA.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: datadog-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of Datadog apiKey\n  appKey: # Required: base64 encoded value of Datadog appKey\n  datadogSite: # Optional: base64 encoded value of Datadog site\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-datadog-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n    # Required: API key for your Datadog account\n  - parameter: apiKey\n    name: datadog-secrets\n    key: apiKey\n    # Required: APP key for your Datadog account\n  - parameter: appKey\n    name: datadog-secrets\n    key: appKey\n    # Optional: Datadog site. Default: \"datadoghq.com\"\n  - parameter: datadogSite\n    name: datadog-secrets\n    key: datadogSite\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # Optional: (Value or AverageValue). Whether the target value is global or average per pod. Default: AverageValue\n    metricType: \"Value\"\n    metadata:\n      # Required: datadog metric query\n      query: \"sum:trace.redis.command.hits{env:none,service:redis}.as_count()\"\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"7\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"120\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\n## Polling intervals and Datadog rate limiting\n\n[API Datadog endpoints are rate\nlimited](https://docs.datadoghq.com/api/latest/rate-limits/). Depending on the\nstate of the `ScaledObject` there are two different parameters to control how\noften (per `ScaledObject`) we query Datadog for a metric.\n\nWhen scaling from 0 to 1, the polling interval is controlled by KEDA, using [the\n`spec.pollingInterval` parameter in the `ScaledObject`\ndefinition](../concepts/scaling-deployments/#pollinginterval). For example, if\nthis parameter is set to `60`, KEDA will poll Datadog for a metric value every\n60 seconds while the number of replicas is 0.\n\nWhile scaling from 1 to N, on top of KEDA, the HPA will also poll regularly\nDatadog for metrics, based on [the `--horizontal-pod-autoscaler-sync-period`\nparameter to the\n`kube-controller-manager`](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/#options),\nwhich by default is 15 seconds. For example, if the `kube-controller-manager`\nwas started with `--horizontal-pod-autoscaler-sync-period=30`, the HPA will poll\nDatadog for a metric value every 30 seconds while the number of replicas is\nbetween 1 and N.\n\n## Multi-Query Support\n\nTo reduce issues with API rate limiting from Datadog, it is possible to send a single query, which contains multiple queries, comma-seperated.\nWhen doing this, the results from each query are aggregated based on the `queryAggregator` value (eg: `max` or `average`).\n\n> 💡 **NOTE:** Because the average/max aggregation operation happens at the scaler level, there won't be any validation or errors if the queries don't make sense to aggregate. Be sure to read and understand the two patterns below before using Multi-Query.\n\n### Example 1 - Aggregating Similar Metrics\n\nSimple aggregation works well, when wanting to scale on more than one metric with similar return values/scale (ie. where multiple metrics can use a single `queryValue` and still make sense).\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated querys count as a single API call:\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300)),per_second(sum:http.requests{service:myservice1}).rollup(avg, 600)\"\n      # According to aggregated results, how to scale the TargetRef\n      queryValue: \"100\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"average\"\n      # Optional: The time window (in seconds) to retrieve metrics from Datadog. Default: 90\n      age: \"600\"\n      # Optional: The metric value to return to the HPA if a metric value wasn't found for the specified time window\n      metricUnavailableValue: \"0\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nThe example above looks at the `http.requests` value for a service; taking two views of the same metric (max vs avg, and different time windows), and then uses a scale value which is the average of them both.\n\nThis works particularly well when scaling against the same metric, but with slightly different parameters, or methods like ```week_before()``` for example.\n\n### Example 2 - Driving scale directly\n\nWhen wanting to scale on non-similar metrics, whilst still benefiting from reduced API calls with multi-query support, the easiest way to do this is to make each query directly return the desired scale (eg: number of pods), and then `max` or `average` the results to get the desired target scale.\n\nThis can be done by adding arithmetic to the queries, which makes them directly return the number of pods that should be running.\n\nFollowing this pattern, and then setting `queryValue: 1` and `metricType: AverageValue` results in the desired number of pods being spawned directly from the results of the metric queries.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    # `AverageValue` tracks the query results divided by the number of running containers\n    metricType: \"AverageValue\"\n    metadata:\n      # Comma-seperated queries count as a single API call:\n      ## This example returns \"http.requests\" @ 180 requests-per-second per-pod,\n      ## and \"http.backlog\" size of 30 per-pod\n      query: \"per_second(sum:http.requests{service:myservice1}).rollup(max, 300))/180,per_second(sum:http.backlog{service:myservice1}).rollup(max, 300)/30\"\n      # Setting query value to 1 and metricType to \"AverageValue\" allows the metric to dictate the number of pods from it's own arthimetic.\n      queryValue: \"1\"\n      # How to aggregate results from multi-query queries. Default: 'max'\n      queryAggregator: \"max\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nUsing the example above, if we assume that `http.requests` is currently returning `360`, dividing that by `180` in the query, results in a value of `2`; if `http.backlog` returns `90`, dividing that by `30` in the query, results in a value of `3`. With the `max` Aggregator set, the scaler will set the target scale to `3` as that is the higher value from all returned queries.\n\n## Cases of unexpected metrics value in DataDog API response\n\n### Latest data point is unavailable\n\nBy default Datadog scaler retrieves the metrics with time window from `now - metadata.age (in seconds)` to `now`, however, some kinds of queries need a small delay (usually 30 secs - 2 mins) before data is available when querying from the API. In this case, adjust `timeWindowOffset` to ensure that the latest point of your query is always available.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue\n\n### The value of last data point is inaccurate\n\nDatadog implicitly rolls up data points automatically with the `avg` method, effectively displaying the average of all data points within a time interval for a given metric. Essentially, there is a rollup for each point. The values at the end attempt to have the rollup applied. When this occurs, it looks at a X second bucket according to your time window, and will default average those values together. Since this is the last point in the query, there are no other values to average with in that X second bucket. This leads to the value of last data point that was not rolled up in the same fashion as the others, and leads to an inaccurate number. In these cases, adjust `lastAvailablePointOffset` to 1 to use the second to last points of an API response would be the most accurate.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: datadog-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: datadog\n    metricType: \"AverageValue\"\n    metadata:\n      query: \"sum:trace.express.request.hits{*}.as_rate()\"\n      queryValue: \"100\"\n      age: \"90\"\n      metricUnavailableValue: \"0\"\n      # Optional: The delayed time window offset (in seconds) to wait for the metric to be available. The values of some queries might be not available at now and need a small delay to become available, try to adjust it if you encounter this issue. Default: 0\n      timeWindowOffset: \"30\"\n      # Optional: The offset to retrieve the X to last data point. The value of last data point of some queries might be inaccurate, try to adjust to 1 if you encounter this issue. Default: 0\n      lastAvailablePointOffset: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-datadog-secret\n```\n\nCheck [here](https://github.com/kedacore/keda/pull/3954#discussion_r1042820206) for the details of this issue.\n"
  },
  {
    "path": "content/docs/2.9/scalers/elasticsearch.md",
    "content": "+++\ntitle = \"Elasticsearch\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on elasticsearch search template query result.\"\ngo_file = \"elasticsearch_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `elasticsearch` trigger that scales based on result of an [elasticsearch search template](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-template.html) query.\n\nThe trigger always requires the following information:\n\n```yaml\ntriggers:\n  - type: elasticsearch\n    metadata:\n      addresses: \"http://localhost:9200\"\n      username: \"elastic\"\n      passwordFromEnv: \"ELASTIC_PASSWORD\"\n      index: \"my-index\"\n      searchTemplateName: \"my-search-template-name\"\n      parameters: \"param1:value1;param2:value2\"\n      valueLocation: \"hits.total.value\"\n      targetValue: \"1.1\"\n      activationTargetValue: \"5.5\"\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Elasticsearch cluster client nodes.\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Elasticsearch cluster.\n- `index` - Index to run the search template query on. It supports multiple indexes separated by a semicolon character ( `;` ).\n- `searchTemplateName` - The search template name to run.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `parameters` - Parameters that will be used by the search template. It supports multiple params separated by a semicolon character ( `;` ).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using a username/password or apiKey/cloudID if you're using using ElasticSearch on Elastic Cloud.\n\n**Password Authentication:**\n\n- `username` - Username to authenticate with to Elasticsearch cluster.\n- `password` - Password for configured user to login to Elasticsearch cluster.\n\n**Cloud ID and API Key Authentication:**\n\n[Cloud ID](https://www.elastic.co/guide/en/cloud/current/ec-cloud-id.html) and API Key can be used for Elastic Cloud Service.\n\n- `cloudID` - CloudID to connect with ElasticSearch on Elastic Cloud.\n- `apiKey` - API key to authenticate with ElasticSearch on Elastic Cloud.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `elasticsearch` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: elasticsearch-secrets\ntype: Opaque\ndata:\n  password: cGFzc3cwcmQh\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-elasticsearch-secret\nspec:\n  secretTargetRef:\n  - parameter: password\n    name: elasticsearch-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: elasticsearch-scaledobject\nspec:\n  scaleTargetRef:\n    name: \"deployment-name\"\n  triggers:\n    - type: elasticsearch\n      metadata:\n        addresses: \"http://localhost:9200\"\n        username: \"elastic\"\n        index: \"my-index\"\n        searchTemplateName: \"my-search-template\"\n        valueLocation: \"hits.total.value\"\n        targetValue: \"10\"\n        parameters: \"dummy_value:1\"\n      authenticationRef:\n        name: keda-trigger-auth-elasticsearch-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/etcd.md",
    "content": "+++\ntitle = \"Etcd\"\navailability = \"v2.9+\"\nmaintainer = \"Huawei Cloud\"\ndescription = \"Scale applications based on an etcd key-value pair. By watching an etcd key, a passively received push mode, the scaler can activate applications with lower load usage than frequent pull mode\"\ngo_file = \"etcd_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `etcd` trigger that scales based on an etcd key-value pair.\n\n```yaml\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n        activationValue: '0.5'\n        watchProgressNotifyInterval: '600'\n```\n\n**Parameter list:**\n\n- `endpoints` - Etcd servers' endpoints information. It supports multiple endpoints split by a comma character (`,`).\n- `watchKey` - Name of the etcd key used for the scaler client to get/watch the etcd value from etcd servers.\n- `value` - Target relation between the scaled workload and the etcd value. It will be calculated following this formula: relation = (etcd value) / (scaled workload pods). (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `watchProgressNotifyInterval` - Set this parameter to the same as `--experimental-watch-progress-notify-interval` parameter of etcd servers. (Default: `600`, units are seconds, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by tls. It is required you should set `tls` to `enable`. If required for your etcd configuration, you may also provide a `ca`, `cert`, `key` and `keyPassword`. `cert` and `key` must be specified together.\n\n**Credential based authentication:**\n\n**TLS:**\n\n- `tls` - To enable SSL auth for etcd, set this to `enable`. If not set, TLS for etcd is not used. (Values: `enable`, `disable`, Default: `disable`, Optional)\n- `ca` - Certificate authority file for TLS client authentication. (Optional)\n- `cert` - Certificate for client authentication. (Optional)\n- `key` - Key for client authentication. (Optional)\n- `keyPassword` - If set the `keyPassword` is used to decrypt the provided `key`. (Optional)\n\n### Example\n\nYour etcd cluster no TLS auth:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n```\n\nYour etcd cluster turn on SASL/TLS auth:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-etcd-secrets\n  namespace: default\ndata:\n  tls: ZW5hYmxl\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-etcd-credential\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: tls\n      name: keda-etcd-secrets\n      key: tls\n    - parameter: ca\n      name: keda-etcd-secrets\n      key: ca\n    - parameter: cert\n      name: keda-etcd-secrets\n      key: cert\n    - parameter: key\n      name: keda-etcd-secrets\n      key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: etcd-scaledobject\nspec:\n  scaleTargetRef:\n    name: my-app-target\n  pollingInterval: 30\n  triggers:\n    - type: etcd\n      metadata:\n        endpoints: 172.0.0.1:2379,172.0.0.2:2379,172.0.0.3:2379\n        watchKey: length\n        value: '5.5'\n      authenticationRef:\n        name: keda-trigger-auth-etcd-credential\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/external-push.md",
    "content": "+++\ntitle = \"External Push\"\navailability = \"v2.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external push scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external-push` trigger for an external push scaler.\n\n```yaml\ntriggers:\n- type: external-push\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile: /path/to/tls/cert.pem # optional\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external push scaler implementing `ExternalScaler.StreamIsActive` in externalscaler.proto. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\nThe entire metadata object is passed to the external scaler in `ScaledObjectRef.scalerMetadata`.\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: name\n  namespace: namespace\nspec:\n  scaleTargetRef:\n    name: keda-node\n  triggers:\n  - type: external-push\n    metadata:\n      scalerAddress: external-scaler-service:8080\n      tlsCertFile: /path/to/tls/cert.pem # optional\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/external.md",
    "content": "+++\ntitle = \"External\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on an external scaler.\"\ngo_file = \"external_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `external` trigger for an external scaler.\n\n```yaml\ntriggers:\n- type: external\n  metadata:\n    scalerAddress: external-scaler-service:8080\n    tlsCertFile : /path/to/tls/cert.pem\n```\n\n**Parameter list:**\n\n- `scalerAddress` - Address of the external scaler. Format must be `host:port`.\n- `tlsCertFile` - Location of a certificate to use for the GRPC connection to authenticate with. (Optional)\n\n> For implementing an external scaler, refer to [External Scalers Concept](../concepts/external-scalers.md).\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: keda-redis-test\nspec:\n  scaleTargetRef:\n    name: keda-redis-node\n  triggers:\n  - type: external\n    metadata:\n      scalerAddress: redis-external-scaler-service:8080\n      address: REDIS_HOST\n      password: REDIS_PASSWORD\n      listName: mylist\n      listLength: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/gcp-pub-sub.md",
    "content": "+++\ntitle = \"Google Cloud Platform‎ Pub/Sub\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Google Cloud Platform‎ Pub/Sub.\"\ngo_file = \"gcp_pubsub_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-pubsub` trigger for Google Cloud Platform‎ Pub/Sub.\n\n```yaml\ntriggers:\n- type: gcp-pubsub\n  metadata:\n    subscriptionSize: \"5\" # Deprecated, use mode and value fields instead\n    mode: \"SubscriptionSize\" # Optional - Default is SubscriptionSize - SubscriptionSize or OldestUnackedMessageAge\n    value: \"5.5\" # Optional - Default is 5 for SubscriptionSize | Default is 10 for OldestUnackedMessageAge\n    activationValue: \"10.5\" # Optional - Default is 0\n    subscriptionName: \"mysubscription\" # Required\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\nThe Google Cloud Platform‎ (GCP) Pub/Sub trigger allows you to scale based on the number of messages or oldest unacked message age in your Pub/Sub subscription.\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the required stack driver metrics in order to read the number of messages in the Pub/Sub subscription.\n\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n`subscriptionName` defines the subscription that should be monitored. You can use different formulas:\n\n- Just the subscription name, in which case you will reference a subscription from the current project or the one specified in the credentials file used.\n- Use the full link provided by Google, so that you can reference a subscription that is hosted in another project Eg: `projects/myproject/subscriptions/mysubscription`.\n\nYou can use either `subscriptionSize` to define the target average which the deployment will be scaled on or `mode` and `value` fields. `subscriptionSize` field is deprecated, it is recommended to use `mode` and `value` fields instead. Scaler will not work if you define both `subscriptionSize` and at least one of `mode` or `value`.\nThe mode chooses whether to scale using number of messages `SubscriptionSize` or using oldest unacked message age `OldestUnackedMessageAge`.\nThe `value` determines the target average which the deployment will be scaled on. The default value is 5 for `SubscriptionSize` and 10 for `OldestUnackedMessageAge`.\n\nHere's an [example](https://github.com/kedacore/sample-go-gcppubsub).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\n  namespace: keda-pubsub-test\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    metadata:\n      mode: \"SubscriptionSize\"\n      value: \"5\"\n      subscriptionName: \"mysubscription\" # Required\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Required\n```\n\n### Example using TriggerAuthentication\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: pubsub-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Example using TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      subscriptionName: \"input\" # Required\n```\n\n## Example using ClusterTriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ClusterTriggerAuthentication\nmetadata:\n  name: keda-clustertrigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pubsub-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-pubsub-go\n  triggers:\n  - type: gcp-pubsub\n    authenticationRef:\n      name: keda-clustertrigger-auth-gcp-credentials\n      kind: ClusterTriggerAuthentication\n    metadata:\n      subscriptionName: \"input\" # Required\n```"
  },
  {
    "path": "content/docs/2.9/scalers/gcp-stackdriver.md",
    "content": "+++\ntitle = \"Google Cloud Platform Stackdriver\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric obtained from Stackdriver.\"\ngo_file = \"gcp_stackdriver_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-stackdriver` trigger for GCP Stackdriver. It scales based on a metric obtained from issuing a query to Stackdriver.\n\n```yaml\ntriggers:\n- type: gcp-stackdriver\n  metadata:\n    projectId: my-project-id\n    filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n    targetValue: '100.50'\n    activationTargetValue: \"10.5\" # Optional - Default is 0\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n    alignmentPeriodSeconds: '60'\n    alignmentAligner: mean\n    alignmentReducer: none\n```\n\n**Parameter list:**\n\n- `projectId` - GCP project Id that contains the metric.\n- `filter` - The stackdriver query filter for obtaining the metric. The metric is for the last minute and if multiple values are returned, the first one is used.\n- `targetValue` - Average target value to trigger scaling actions. (Default: `5`, Optional, This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\nThe `credentialsFromEnv` property maps to the name of an environment variable in the scale target (`scaleTargetRef`) that contains the service account credentials (JSON). KEDA will use those to connect to Google Cloud Platform and collect the configured stack driver metrics.\n\nThe `alignmentPeriodSeconds`, `alignmentAligner` and `alignmentReducer` properties controls time series aggregation before the metrics are returned. See below for more details.\n\n### Timeseries alignment properties\nIt is much better to aggregate the time series values before they are returned from stackdriver instead of getting the raw values.\nFor that, you must specify a value of 60 or more for the `alignmentPeriodSeconds` property as well as an alignment operation in the `alignmentAligner` property and/or a reducer in the `alignmentReducer` property.\n\nValid values for the `alignmentAligner` property are: none, delta, interpolate, next_older, min, max, mean, count, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50, percentile_05 and percent_change.\nValid values for the `alignmentReducer` property are: none, mean, min, max, sum, stddev, count_true, count_false, fraction_true, percentile_99, percentile_95, percentile_50 and percentile_05.\n\nFor more information on aggregation, see [here](https://cloud.google.com/monitoring/api/v3/aggregation#aggr-intro).\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\n  namespace: keda-gcp-stackdriver-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n      targetValue: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-stackdriver-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-stackdriver-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-stackdriver-go\n  triggers:\n  - type: gcp-stackdriver\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      projectId: my-project-id\n      filter: 'metric.type=\"storage.googleapis.com/network/received_bytes_count\" AND resource.type=\"gcs_bucket\" AND metric.label.method=\"WriteObject\" AND resource.label.bucket_name=\"my-gcp-bucket\"'\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/gcp-storage.md",
    "content": "+++\ntitle = \"Google Cloud Platform Storage\"\navailability = \"2.7+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given Google Cloud Storage (GCS) bucket.\"\ngo_file = \"gcp_storage_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `gcp-storage` scaler, which scales Kubernetes workloads based on the count of objects in a given Google Cloud Storage (GCS) bucket. This scaler assumes the worker, when run, will process and clear the bucket by deleting/moving objects therein.\n\n```yaml\ntriggers:\n- type: gcp-storage\n  metadata:\n    bucketName: test-bucket\n    targetObjectCount: '100'\n    activationTargetObjectCount: '10' # Optional\n    maxBucketItemsToScan: '1000'\n    credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    credentialsFromEnvFile: GOOGLE_APPLICATION_CREDENTIALS_JSON # Optional\n    blobPrefix:  # Optional. Prefix for the Blob. Use this to specify sub path for the blobs if required. Default : \"\"\n    blobDelimiter: # Optional. Delimiter for identifying the blob Prefix. Default: \"\"\n```\n\n**Parameter list:**\n\n- `bucketName` - Name of the bucket in GCS.\n- `targetObjectCount` - Average target value to trigger scaling actions. (Default: `100`, Optional)\n- `activationTargetObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `maxBucketItemsToScan` - When to stop counting how many objects are in the bucket. (Default: `1000`, Optional)\n- `blobPrefix` - Prefix for the Blob. Use this to specify sub path for the blobs if required. (Default: `\"\"`, Optional)\n- `blobDelimiter` - Delimiter for identifying the blob prefix. (Default: `\"\"`, Optional)\nAs counting the number of objects involves iterating over their metadata it is advised to set this number to the value of `targetObjectCount` * `maxReplicaCount`.\n\nThe metric name will be generated automatically based on the trigger index and `bucketName`, for example: **s0-gcp-storage-bucketName**.\n\nYou can provide in the metadata either `credentialsFromEnv` or `credentialsFromEnvFile`.\n- `credentialsFromEnv` - Set to the name of the environment variable that holds the credential information.\n- `credentialsFromEnvFile` - Set to the name of a json file that holds the credential information.\n\n### Authentication Parameters\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing the service account credentials in JSON.\n\n**Credential based authentication:**\n\n- `GoogleApplicationCredentials` - Service account credentials in JSON.\n\n**Identity based authentication:**\n\nYou can also use `TriggerAuthentication` CRD to configure the authentication using the associated service account of the running machine in Google Cloud. You only need to create a `TriggerAuthentication` as this example, and reference it in the `ScaledObject`. `ClusterTriggerAuthentication` can also be used if you intend to use it globally in your cluster.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\n  namespace: keda-gcp-storage-test\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON\n```\n\n#### Use TriggerAuthentication with Kubernetes secret\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  secretTargetRef:\n  - parameter: GoogleApplicationCredentials\n    name: gcp-storage-secret        # Required. Refers to the name of the secret\n    key: GOOGLE_APPLICATION_CREDENTIALS_JSON       # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n      blobPrefix: blobsubpath # Default : \"\"\n      blobDelimiter: \"/\" # Default: \"\"\n```\n\n#### Use TriggerAuthentication with GCP Identity\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-gcp-credentials\nspec:\n  podIdentity:\n    provider: gcp\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: gcp-storage-scaledobject\nspec:\n  scaleTargetRef:\n    name: keda-gcp-storage-go\n  triggers:\n  - type: gcp-storage\n    authenticationRef:\n      name: keda-trigger-auth-gcp-credentials\n    metadata:\n      bucketName: \"Transactions\"\n      targetObjectCount: \"5\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/graphite.md",
    "content": "+++\ntitle = \"Graphite\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on metrics in Graphite.\"\ngo_file = \"graphite_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `graphite` trigger that scales based on metrics in Graphite.\n\n```yaml\ntriggers:\n- type: graphite\n  metadata:\n    # Required\n    serverAddress: http://<graphite-host>:81\n    metricName: request-count # Note: name to identify the metric\n    query: stats.counters.http.hello-world.request.count.count # Note: query must return a vector/scalar single element response\n    threshold: '10.5'\n    activationThreshold: '5'\n    queryTime: '-10Minutes' # Note: Query time in from argv Seconds/Minutes/Hours\n```\n**Parameter list:**\n\n- `serverAddress` - Address of Graphite\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique\n- `query` - Query to run.\n- `threshold` - Target value to trigger scaling actions. (Default: 100, Optional, This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `queryTime` - Relative time range to execute query against. Please see the [graphite API docs](https://graphite-api.readthedocs.io/en/latest/api.html#from-until) for more information.\n\n### Authentication Parameters\n\nGraphite Scaler supports one type of authentication - basic authentication\n\n**Basic authentication:**\n- `authMode`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n### Examples\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: graphite\n    metadata:\n      serverAddress: http://<graphite-host>:81\n      metricName: LagMetric\n      threshold: '100'\n      query: maxSeries(keepLastValue(reportd.*.gauge.detect.latest_max_time.value, 1))\n      queryTime: '-1Minutes'\n```\n\nHere is an example of a Graphite Scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-graphite-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-graphite-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-graphite-secret\n      key: username\n    - parameter: password\n      name: keda-graphite-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: graphite-scaledobject\n  namespace: default\n  labels:\n    deploymentName: php-apache-graphite\nspec:\n  cooldownPeriod: 10\n  maxReplicaCount: 5\n  minReplicaCount: 0\n  pollingInterval: 5\n  scaleTargetRef:\n    name: php-apache-graphite\n  triggers:\n  - type: graphite\n    metadata:\n      authMode: \"basic\"\n      metricName: https_metric\n      query: https_metric\n      queryTime: -1Hours\n      serverAddress: http://<graphite server>:81\n      threshold: \"100\"\n    authenticationRef:\n        name: keda-graphite-creds\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/huawei-cloudeye.md",
    "content": "+++\ntitle = \"Huawei Cloudeye\"\navailability = \"v1.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a Huawei Cloudeye.\"\ngo_file = \"huawei_cloudeye_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `huawei-cloudeye` trigger that scales based on a Huawei Cloudeye.\n\n```yaml\ntriggers:\n- type: huawei-cloudeye\n  metadata:\n    namespace: SYS.ELB\n    metricName: mb_l7_qps\n    dimensionName: lbaas_instance_id\n    dimensionValue: 5e052238-0346-xxb0-86ea-92d9f33e29d2\n    targetMetricValue: \"5.5\"\n    activationTargetMetricValue: \"1.5\"\n    minMetricValue: \"1.1\" # Deprecated\n```\n\n**Parameter list:**\n\n- `namespace` - Namespace of the metric.The format is service.item; service and item must be strings, must start with a letter, can only contain 0-9/a-z/A-Z/_, the total length of service.item is 3, the maximum is 32.\n- `metricName` - Name of the metric.\n- `dimensionName` - Name of the metric dimension.\n- `dimensionValue` - Value of the metric dimension.\n- `targetMetricValue` - Target value for your metric. (This value can be a float)\n- `activationTargetMetricValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `minMetricValue` - **Deprecated if favor of `activationTargetMetricValue`** Minimum value for your metric. If the actual value of the metric you get from cloudeye is less than the minimum value, then the scaler is not active. (This value can be a float)\n- `metricCollectionTime` - Collection time of the metric in seconds. Equivalent to the earliest start time of the end time. (default: 300)\n- `metricFilter` - Aggregation method of the metric. (Values: `average`, `max`, `min`, `sum`, Default: `average`, Optional)\n- `metricPeriod` - Granularity of the metric in seconds. (Default: 300, Optional)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authenticate by providing a set of IAM credentials.\n\n**Credential based authentication:**\n\n- `IdentityEndpoint` - Identity Endpoint.\n- `ProjectID` - Project ID.\n- `DomainID` - Id of domain.\n- `Domain` - Domain.\n- `Region` - Region.\n- `Cloud` - Cloud name. (Default: `myhuaweicloud.com`, Optional)\n- `AccessKey` - Id of the user.\n- `SecretKey` - Access key for the user to authenticate with.\n\nThe user will need access to read data from Huawei Cloudeye.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-huawei-secrets\n  namespace: keda-test\ndata:\n  IdentityEndpoint: <IdentityEndpoint>\n  ProjectID: <ProjectID>\n  DomainID: <DomainID>\n  Region: <Region>\n  Domain: <Domain>\n  AccessKey: <AccessKey>\n  SecretKey: <SecretKey>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-huawei-credential\n  namespace: keda-test\nspec:\n  secretTargetRef:\n  - parameter: IdentityEndpoint      # Required.\n    name: keda-huawei-secrets        # Required.\n    key: IdentityEndpoint            # Required.\n  - parameter: ProjectID             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: ProjectID                   # Required.\n  - parameter: DomainID              # Required.\n    name: keda-huawei-secrets        # Required.\n    key: DomainID                    # Required.\n  - parameter: Region                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Region                      # Required.\n  - parameter: Domain                # Required.\n    name: keda-huawei-secrets        # Required.\n    key: Domain                      # Required.\n  - parameter: AccessKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: AccessKey                   # Required.\n  - parameter: SecretKey             # Required.\n    name: keda-huawei-secrets        # Required.\n    key: SecretKey                   # Required.\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: huawei-cloudeye-scaledobject\n  namespace: keda-test\nspec:\n  scaleTargetRef:\n    name: nginx-deployment\n  maxReplicaCount: 5\n  minReplicaCount: 2\n  triggers:\n  - type: huawei-cloudeye\n    metadata:\n      namespace: SYS.ELB\n      dimensionName: lbaas_instance_id\n      dimensionValue: 5e052238-0346-47b0-xxea-92d9f33e29d2\n      metricName: mb_l7_qps\n      targetMetricValue: \"100\"\n      minMetricValue: \"1\"\n    authenticationRef:\n      name: keda-trigger-auth-huawei-credential\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/ibm-mq.md",
    "content": "+++\ntitle = \"IBM MQ\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on IBM MQ Queue\"\ngo_file = \"ibmmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `ibmmq` trigger for IBM MQ Queue.\n\n```yaml\ntriggers:\n- type: ibmmq\n  metadata:\n    host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n    queueManager: <queue-manager> # REQUIRED - Your queue manager\n    queueName: <queue-name> # REQUIRED - Your queue name\n    tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n    queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n    activationQueueDepth: <activation-queue-depth> # OPTIONAL - Activation queue depth target. Default: 0 messages\n    usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n    passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n```\n\n**Parameter list:**\n\n- `host` - IBM MQ Queue Manager Admin REST Endpoint. Example URI endpoint structure on IBM cloud `https://example.mq.appdomain.cloud/ibmmq/rest/v2/admin/action/qmgr/QM/mqsc`.\n- `queueManager` - Name of the queue manager from which messages will be consumed.\n- `queueName` - Name of the Queue within the Queue Manager defined from which messages will be consumed.\n- `tlsDisabled` - Can be set to 'true' to disable TLS. (Values: `true`, `false` , Default: `false`, Optional)\n- `queueDepth` - Queue depth Target for HPA. (Default: `5`, Optional)\n- `activationQueueDepth` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to IBM MQ:\n\n**Authentication Parameters**\n\n- `ADMIN_USER` - REQUIRED - The admin REST endpoint username for your MQ Queue Manager`.\n- `ADMIN_PASSWORD` - REQUIRED - The admin REST endpoint API key for your MQ Queue Manager.\n- `usernameFromEnv` - Provide admin username from env instead of as a secret. (Optional)\n- `passwordFromEnv` - Provide admin password from env instead of as a secret. (Optional)\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-ibmmq-secret\ndata:\n  ADMIN_USER: <encoded-username> # REQUIRED - Admin Username\n  ADMIN_PASSWORD: <encoded-password> # REQUIRED - Admin Password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: ibmmq-scaledobject\n  namespace: default\n  labels:\n    deploymentName: ibmmq-deployment\nspec:\n  scaleTargetRef:\n    name: ibmmq-deployment\n  pollingInterval: 5 # OPTIONAL - Default: 30 seconds\n  cooldownPeriod: 30 # OPTIONAL - Default: 300 seconds\n  maxReplicaCount: 18 # OPTIONAL - Default: 100\n  triggers:\n    - type: ibmmq\n      metadata:\n        host: <ibm-host> # REQUIRED - IBM MQ Queue Manager Admin REST Endpoint\n        queueManager: <queue-manager> # REQUIRED - Your queue manager\n        queueName: <queue-name> # REQUIRED - Your queue name\n        tlsDisabled: <TLS enabled/disabled> # OPTIONAL - Set 'true' to disable TLS. Default: false\n        queueDepth: <queue-depth> # OPTIONAL - Queue depth target for HPA. Default: 5 messages\n        usernameFromEnv: <admin-user> # Optional: Provide admin username from env instead of as a secret\n        passwordFromEnv: <admin-password> # Optional: Provide admin password from env instead of as a secret\n      authenticationRef:\n        name: keda-ibmmq-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-ibmmq-trigger-auth\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-ibmmq-secret\n      key: ADMIN_USER\n    - parameter: password\n      name: keda-ibmmq-secret\n      key: ADMIN_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/influxdb.md",
    "content": "+++\ntitle = \"InfluxDB\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on InfluxDB queries\"\ngo_file = \"influxdb_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `influxdb` trigger that scales based on the results of a InfluxDB query.\n\n```yaml\ntriggers:\n  - type: influxdb\n    metadata:\n      serverURL: http://influxdb:8086\n      organizationName: influx-org\n      organizationNameFromEnv: INFLUXDB_ORG_NAME # Optional: You can use this instead of `organizationName` parameter. See details in \"Parameter List\" section\n      thresholdValue: '4.4'\n      activationThresholdValue: '6.2'\n      query: |\n        from(bucket: \"bucket-of-interest\")\n        |> range(start: -12h)\n        |> filter(fn: (r) => r._measurement == \"stat\")\n      authToken: some-auth-token\n      authTokenFromEnv: INFLUXDB_AUTH_TOKEN # Optional: You can use this instead of `authToken` parameter. See details in \"Parameter List\" section\n      metricName: influx-metric # Optional: This value will default to organization name if not set by the user (metrics name value would be then `influxdb-influx_org`)\n```\n\n**Parameter list:**\n\n- `authToken` - Authentication token needed for the InfluxDB client to communicate with an associated server.\n- `authTokenFromEnv` - Defines the authorization token, similar to `authToken`, but reads it from an environment variable on the scale target.\n- `organizationName` - Organization name needed for the client to locate all information contained in that [organization](https://docs.influxdata.com/influxdb/v2.0/organizations/) such as buckets, tasks, etc.\n- `organizationNameFromEnv` - Defines the organization name, similar to `organizationName`, but reads it from an environment variable on the scale target.\n- `serverURL` - Holds the url value of the InfluxDB server.\n- `thresholdValue` - Provided by the user. This value can vary from use case to use case depending on the data of interest, and is needed to trigger the scaling in/out depending on what value comes back from the query. (This value can be a float)\n- `activationThresholdValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `query` - Flux query that will yield the value for the scaler to compare the `thresholdValue` against.\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based organization name. If using more than one trigger it is required that all `metricName`(s) be unique. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate by using an authorization token.\n\n**Authorization Token Authentication:**\n\n- `authToken` - Authorization token for InfluxDB server.\n\n### Example\n\nBelow is an example of how to deploy a scaled object with the `InfluxDB` scale trigger.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: influxdb-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: nginx-worker\n  triggers:\n    - type: influxdb\n      metadata:\n        serverURL: http://influxdb:8086\n        organizationNameFromEnv: INFLUXDB_ORG_NAME\n        thresholdValue: '4'\n        activationThresholdValue: '6'\n        query: |\n          from(bucket: \"bucket-of-interest\")\n          |> range(start: -12h)\n          |> filter(fn: (r) => r._measurement == \"stat\")\n        authTokenFromEnv: INFLUXDB_AUTH_TOKEN\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/kubernetes-workload.md",
    "content": "+++\ntitle = \"Kubernetes Workload\"\navailability = \"v2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of running pods that match the given selectors.\"\ngo_file = \"kubernetes_workload_scaler\"\n+++\n\n### Trigger Specification\n\n```yaml\ntriggers:\n- type: kubernetes-workload\n  metadata:\n    podSelector: 'app=backend'\n    value: '0.5'\n    activationValue: '3.1'\n```\n\n**Parameter list:**\n\n- `podSelector` - [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors) that will be used to get the pod count. It supports multiple selectors split by a comma character (`,`). It also supports [set-based requirements](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) and a mix of them.\n- `value` - Target relation between the scaled workload and the amount of pods which matches the selector. It will be calculated following this formula: `relation = (pods which match selector) / (scaled workload pods)`. (This value can be a float)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> 💡 **Note:** The search scope is limited to the namespace where the `ScaledObject` is deployed.\n\nThe count excludes terminated pods, i.e. [pod status](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#podstatus-v1-core) `phase` equals `Succeeded` or `Failed`.\n\n### Authentication Parameters\n\nThe own KEDA's identity is used to list the pods, so no extra configuration is needed here.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: workload-scaledobject\nspec:\n  scaleTargetRef:\n    name: workload-deployment\n  triggers:\n  - type: kubernetes-workload\n    metadata:\n      podSelector: 'app=backend, deploy notin (critical, monolith)'\n      value: '3'\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/liiklus-topic.md",
    "content": "+++\ntitle = \"Liiklus Topic\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Liiklus Topic.\"\ngo_file = \"liiklus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `liiklus` trigger for Liiklus Topic.\n\n```yaml\ntriggers:\n- type: liiklus\n  metadata:\n    # Required\n    address: localhost:6565\n    group: my-group\n    topic: test-topic\n    # Optional\n    lagThreshold: \"50\"\n    # Optional\n    activationLagThreshold: \"20\"\n    groupVersion: 1\n```\n\n**Parameter list:**\n\n- `address` - Address of the gRPC liiklus API endpoint.\n- `group` - Name of consumer group.\n- `topic` - Topic to monitor and scale based on `lagThreshold`.\n- `lagThreshold` - Value to trigger scaling actions for. (Default: `10`, Optional)\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `groupVersion` - Version of the group to consider when looking at messages. See [docs](https://github.com/bsideup/liiklus/blob/22efb7049ebcdd0dcf6f7f5735cdb5af1ae014de/app/src/test/java/com/github/bsideup/liiklus/GroupVersionTest.java). (Default: `0`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: liiklus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: function-deployment\n  pollingInterval: 30\n  triggers:\n  - type: liiklus\n    metadata:\n      # Required\n      address: localhost:6565\n      group: my-group       # Make sure that this consumer group name is the same one as the one that is consuming topics\n      topic: test-topic\n      # Optional\n      lagThreshold: \"50\"    # Default value is set to 10\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/loki.md",
    "content": "+++\ntitle = \"Loki\"\navailability = \"v2.9+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Loki query result.\"\ngo_file = \"loki_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `loki` trigger that scales based on a Loki query result. Here is an example of providing values in metadata:\n\n```yaml\ntriggers:\n- type: loki\n  metadata:\n    # Required fields:\n    serverAddress: http://<loki-host>:3100 # Note: loki server URL \n    query: sum(rate({filename=\"/var/log/syslog\"}[1m])) # Note: query must return a vector/scalar single element response\n    threshold: '0.7'\n    # Optional fields:\n    activationThreshold: '2.50'\n    tenantName: Tenant1 # Optional. X-Scope-OrgID header for specifying the tenant name in a multi-tenant setup.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Loki. Set to `false` the scaler will return error when Loki target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Loki endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - URL of Loki server.\n- `query` - LogQL query to run. The query must return a vector/scalar single element response.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `tenantName` - The `X-Scope-OrgID` header for specifying the tenant name in a multi-tenant setup. (Optional)\n- `ignoreNullValues` - Value to reporting error when Loki target is lost. (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs. (Values: `true`,`false`, Default: `false`, Optional)\n- `authModes` - Authentication mode to be used. (Values: `bearer`,`basic`, Optional)\n\n### Authentication Parameters\n\nLoki doesn't provide any kind of authentication out of the box. However, most commonly Loki is configured along with a Basic Auth or Bearer Auth, which are the only valid options for authentication here.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional, For convenience this has been marked optional as many applications implement basic auth with a username as apikey and password as empty.)\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n```\n\nHere is an example of a loki scaler with Bearer Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-loki-secret\n      key: bearerToken\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n\nHere is an example of a loki scaler with Basic Authentication, where the `Secret` and `TriggerAuthentication` are defined as follows:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-loki-secret\n  namespace: default\ndata:\n  username: dXNlcm5hbWU=\n  password: cGFzc3dvcmQ=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-loki-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-loki-secret\n      key: username\n    - parameter: password\n      name: keda-loki-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: loki-scaledobject\n  namespace: default\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: nginx\n  triggers:\n    - type: loki\n      metadata:\n        serverAddress: http://<loki-host>:3100\n        threshold: '0.7'\n        query: sum(rate({filename=\"/var/log/syslog\"}[1m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-loki-creds\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/memory.md",
    "content": "+++\ntitle = \"Memory\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on memory metrics.\"\ngo_file = \"cpu_memory_scaler\"\n+++\n\n> **Notice:**\n> - This scaler **requires prerequisites**. See the 'Prerequisites' section.\n> - This scaler will never scale to 0 and even when user defines multiple scaler types (eg. Kafka + cpu/memory, or Prometheus + cpu/memory), the deployment will never scale to 0.\n> - This scaler only applies to ScaledObject, not to Scaling Jobs.\n\n### Prerequisites\n\nKEDA uses standard `cpu` and `memory` metrics from the Kubernetes Metrics Server, which is not installed by default on certain Kubernetes deployments such as EKS on AWS. Additionally, the `resources` section of the relevant Kubernetes Pods must include `requests` (at a minimum).\n\n- The Kubernetes Metrics Server must be installed. Installation instructions vary based on your Kubernetes provider.\n- The configuration for your Kubernetes Pods must include a `resources` section with specified `requests`. See [Resource Management for Pods and Containers](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). If the resources section is empty (`resources: {}` or similar) the error `missing request for {cpu/memory}` occurs.\n\n```yaml\n# a working example of resources with specified requests\nspec:\n  containers:\n  - name: app\n    image: images.my-company.example/app:v4\n    resources:\n      requests:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n```\n\n### Trigger Specification\n\nThis specification describes the `memory` trigger that scales based on memory metrics.\n\n```yaml\ntriggers:\n- type: memory\n  metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n  metadata:\n    type: Utilization # Deprecated in favor of trigger.metricType; allowed types are 'Utilization' or 'AverageValue'\n    value: \"60\"\n    containerName: \"\" # Optional. You can use this to target a specific container in a pod\n```\n\n**Parameter list:**\n\n- `type` - Type of metric to use. Options are `Utilization`, or `AverageValue`.\n- `value` - Value to trigger scaling actions for:\n\t- When using `Utilization`, the target value is the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods.\n\t- When using `AverageValue`, the target value is the target value of the average of the metric across all relevant pods (quantity).\n- `containerName` - Name of the specific container to scale based on its memory, rather than the entire pod. Defaults to empty if not specified.\n\n> 💡 **NOTE:** `containerName` parameter requires Kubernetes cluster version 1.20 or higher with `HPAContainerMetrics` feature enabled. Please see [container resource metrics](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics) for more information.\n\n> 💡 **NOTE:** The `type` parameter is deprecated in favor of the global `metricType` and will be removed in a future release. Users are advised to use `metricType` instead.\n\n### Example\n\nThe following example targets memory utilization of entire pod. If the pod has multiple containers, it will be sum of all the containers in it.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n```\n\nThe following example targets memory utilization of a specific container (`foo`) in a pod.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: memory-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: memory\n    metricType: Utilization # Allowed types are 'Utilization' or 'AverageValue'\n    metadata:\n      value: \"50\"\n      containerName: \"foo\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/metrics-api.md",
    "content": "+++\ntitle = \"Metrics API\"\navailability = \"v2.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a metric provided by an API\"\ngo_file = \"metrics_api_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `metrics-api` trigger that scales based on a metric value provided by an API.\n\nThis scaler allows users to utilize **any existing APIs** as a metric provider.\n\nHere is an example of trigger configuration using metrics-api scaler:\n\n```yaml\ntriggers:\n- type: metrics-api\n  metadata:\n    targetValue: \"8.8\"\n    activationTargetValue: \"3.8\"\n    url: \"http://api:3232/api/v1/stats\"\n    valueLocation: \"components.worker.tasks\"\n```\n\n**Parameter list:**\n\n- `url` - Full URL of the API operation to call to get the metric value (eg. `http://app:1317/api/v1/stats`).\n- `valueLocation` - [GJSON path notation](https://github.com/tidwall/gjson#path-syntax) to refer to the field in the payload containing the metric value.\n- `targetValue` - Target value to scale on. When the metric provided by the API is equal or higher to this value, KEDA will start scaling out. When the metric is 0 or less, KEDA will scale down to 0. (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n\n\n### Authentication Parameters\n\nMetrics Scaler API supported three types of authentication - API Key based authentication, basic authentication and TLS\nauthentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. Specify `authMode` and other trigger parameters\n along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**API Key based authentication:**\n- `authMode`: It must be set to `apiKey` in case of API key Authentication. Specify this in trigger configuration.\n- `method` - This specifies the possible methods API Key based authentication supports. Possible values are `header` and `query`. `header` is the default method. Specify this in trigger configuration.\n- `keyParamName` - This is either header key or query param used for passing apikey. Default header is `X-API-KEY` and default query param is `api_key`. Specify this in trigger configuration. If your implementation has different key, please specify it here.\n- `apiKey` - API Key needed for authentication.\n\n**Basic authentication:**\n- `authMode` - It must be set to `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. (Optional)\n\n**TLS authentication:**\n- `authMode` - It must be set to `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication.\n- `key` - Key for client authentication. (Optional)\n\n**Bearer authentication:**\n- `authMode` - It must be set to `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `token` - Token that should be placed in the `Authorization` header. The header will be `Authorization: Bearer {token}`.\n\n### Example\n\nHere is a full example of scaled object definition using Metric API trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n```\n\nWhen checking current metric Metrics API scaler sends GET request to provided `url` and then uses `valueLocation`\nto access the value in response's payload.\n\nThe above example expects that the API endpoint will return response similar to this one:\n```json\n{\n  \"components\": {\n    \"worker\": {\n      \"tasks\": 12,\n      ...\n    },\n    ...\n  },\n  ...\n}\n```\nAssuming such response, Metrics API trigger will figure out that current metric value is 12.\n\n> 💡 **NOTE:**The value of the metric can either be an integral unquoted json number type (e.g. 123). Or a quantity (e.g. \"123\", \"1.23\", \"10Mi\").\n\nHere is an example of a metric scaler with API Key based authentication,\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  apiKey: \"APIKEY\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: apiKey\n      name: keda-metric-api-secret\n      key: apiKey\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"apiKey\"\n        method: \"query\"\n        keyParamName: \"QUERY_KEY\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  token: \"PlaceYourTokenHere\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: token\n      name: keda-metric-api-secret\n      key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"bearer\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\nHere is an example of a metric scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-metric-api-secret\n      key: username\n    - parameter: password\n      name: keda-metric-api-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"basic\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n\n\nHere is an example of a metric scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-metric-api-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-metric-api-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-metric-api-secret\n      key: cert\n    - parameter: key\n      name: keda-metric-api-secret\n      key: key\n    - parameter: ca\n      name: keda-metric-api-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: http-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: metrics-api\n      metadata:\n        targetValue: \"7\"\n        url: \"http://api:3232/components/stats\"\n        valueLocation: 'components.worker.tasks'\n        authMode: \"tls\"\n      authenticationRef:\n        name: keda-metric-api-creds\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/mongodb.md",
    "content": "+++\ntitle = \"MongoDB\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MongoDB queries.\"\navailability = \"v2.1+\"\ngo_file = \"mongo_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mongodb` trigger that scales based on result of MongoDB query.\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # name of an environment variable containing a valid MongoDB connection string\n      connectionStringFromEnv: MongoDB_CONNECTION_STRING\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name\n      metricName: \"global-metric\"\n```\n\nAlternatively, you can configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n  - type: mongodb\n    metadata:\n      # host name of the MongoDB server. Example of mongodb service: \"mongodb-svc.<namespace>.svc.cluster.local\"\n      host: mongodb-svc.default.svc.cluster.local\n      # port number of the MongoDB server.\n      port: \"27017\"\n      # username credential for connecting to the MongoDB server\n      username: test_user\n      # name of an environment variable containing a valid password for connecting to the MongoDB server\n      passwordFromEnv: MongoDB_Password\n      # Required: database name\n      dbName: \"test\"\n      # Required: collection name\n      collection: \"test_collection\"\n      # Required: query expr, used by filter data\n      query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n      # Required: according to the number of query result, to scale the TargetRef\n      queryValue: \"1\"\n      # Optional: according to the number of query result, the scaler is active\n      activationQueryValue: \"1\"\n      # Optional: The generated metric name would be mongodb-global-metric. Here mongodb- use as a prefix for metric name.\n      metricName: \"global-metric\"\n```\n\n>**NOTE:** If **metricName** is not set, then one is generated based on trigger index and the `collection`, for example: **s0-mongodb-test_collection**\n\n**Parameter list:**\n\nThe `mongodb` trigger always requires the following information:\n\n- `dbName` - Name of the database.\n- `collection` - Name of the collection.\n- `query` - A MongoDB query that should return single numeric value.\n- `queryValue` - A threshold that will define when scaling should occur.\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\nTo connect to the MongoDB server, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MongoDB connection string for connecting to the MongoDB server.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MongoDB server.\n\nWhen configuring with a connection string, you can use this URL format:\n\n```\nmongodb://<username>:<password>@mongodb-svc.<namespace>.svc.cluster.local:27017/<database_name>\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and collection name. For example: **s1-mongodb-test_collection**. The value will be prefixed with `s{triggerIndex}-mongodb-` .\n\n### Authentication Parameters\n\nAs an alternative to environment variables, You can authenticate with the MongoDB server by using connection string or password authentication via `TriggerAuthentication` or `ClusterTriggerAuthentication` configuration.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MongoDB server.\n\n**Password Authentication:**\n\n- `host` - The host name of the MongoDB server.\n- `port` - The port number of the MongoDB server.\n- `username` - Username to authenticate with to MongoDB database.\n- `password` - Password for the configured user to login to MongoDB server.\n- `dbName` - Name of the database.\n\n### Example\n\nHere is an example of how to deploy a scaled Job with the `MongoDB` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledJob\nmetadata:\n  name: mongodb-job\nspec:\n  jobTargetRef:\n    template:\n      spec:\n        containers:\n          - name: mongodb-update\n            image: 1314520999/mongodb-update:latest\n            args:\n            - --dataBase=test\n            - --collection=test_collection\n            imagePullPolicy: IfNotPresent\n        restartPolicy: Never\n    backoffLimit: 1\n  pollingInterval: 30             # Optional. Default: 30 seconds\n  maxReplicaCount: 30             # Optional. Default: 100\n  successfulJobsHistoryLimit: 0   # Optional. Default: 100. How many completed jobs should be kept.\n  failedJobsHistoryLimit: 10      # Optional. Default: 100. How many failed jobs should be kept.\n  triggers:\n    - type: mongodb\n      metadata:\n        dbName: \"test\"\n        collection: \"test_collection\"\n        query: '{\"region\":\"eu-1\",\"state\":\"running\",\"plan\":\"planA\"}'\n        queryValue: \"1\"\n        metricName: \"global-metric\"\n      authenticationRef:\n        name: mongodb-trigger\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: mongodb-trigger\nspec:\n  secretTargetRef:\n    - parameter: connectionString\n      name: mongodb-secret\n      key: connect\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mongodb-secret\ntype: Opaque\ndata:\n  connect: bW9uZ29kYjovL3Rlc3RfdXNlcjp0ZXN0X3Bhc3N3b3JkQG1vbmdvZGItc3ZjLm1vbmdvREIuc3ZjLmNsdXN0ZXIubG9jYWw6MjcwMTcvdGVzdA==\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/mssql.md",
    "content": "+++\ntitle = \"MSSQL\"\navailability = \"v2.2+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on Microsoft SQL Server (MSSQL) query results.\"\ngo_file = \"mssql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mssql` trigger that scales based on the results of a [Microsoft SQL Server](https://www.microsoft.com/sql-server/) (MSSQL) query result. This trigger supports local [MSSQL containers](https://hub.docker.com/_/microsoft-mssql-server) as well as SQL Server endpoints hosted in the cloud, such as [Azure SQL Database](https://azure.microsoft.com/services/sql-database/).\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    connectionStringFromEnv: MSSQL_CONNECTION_STRING\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: \"5.5\"\n    activationTargetValue: '5'\n    metricName: backlog_process_count # optional - the generated value would be `mssql-{sha256hash}`\n```\n\n> 💡 **NOTE:** The connection string format supported by this scaler has some incompatibilities with connection string formats supported by other platforms, like .NET. For example, the MSSQL instance's port number must be separated into its own `Port` property instead of adding it to the `Server` property. You can learn more about all the supported connection string formats for this mssql scaler [here](https://github.com/denisenkom/go-mssqldb#the-connection-string-can-be-specified-in-one-of-three-formats).\n\nAlternatively, you configure connection parameters explicitly instead of providing a connection string:\n\n```yaml\ntriggers:\n- type: mssql\n  metadata:\n    username: \"kedaUser\"\n    passwordFromEnv: MSSQL_PASSWORD\n    host: mssqlinst.namespace.svc.cluster.local\n    port: \"1433\" # optional\n    database: test_db_name\n    query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    targetValue: 1\n    metricName: backlog_process_count # optional - the generated value would be `mssql-test_db_name`\n```\n\nThe `mssql` trigger always requires the following information:\n\n- `query` - A [T-SQL](https://docs.microsoft.com/sql/t-sql/language-reference) query that returns a single numeric value. This can be a regular query or the name of a stored procedure.\n- `targetValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the Horizontal Pod Autoscaler (HPA). (This value can be a float)\n- `activationTargetValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MSSQL documentation](https://learn.microsoft.com/en-us/sql/t-sql/language-elements/coalesce-transact-sql) for more information on the `COALESCE` function.\n\nTo connect to the MSSQL instance, you can provide either:\n\n- `connectionStringFromEnv` - The name of an environment variable containing a valid MSSQL connection string.\n\nOr provide more detailed connection parameters explicitly (a connection string will be generated for you at runtime):\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (Default: 1433, Optional)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `passwordFromEnv` - The name of an environment variable containing the password credential for connecting to the MSSQL instance.\n\nWhen configuring with a connection string, you can use either a URL format (note the URL encoding of special characters):\n\n```\nsqlserver://user1:Password%231@example.database.windows.net:1433?database=AdventureWorks\n```\n\nOr the more traditional ADO format:\n\n```\nServer=example.database.windows.net;Port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;\n```\n\nYou can also optionally assign a name to the metric using the `metricName` value. If not specified, the `metricName` will be generated automatically based on trigger index and the `database` value (if specified), or the `host` value, or will be in the form `s{triggerIndex}-mssql-{sha256hash}` where `{sha256hash}` is a SHA-256 hash of the connection string.\n\n### Authentication parameters\n\nAs an alternative to using environment variables, you can authenticate with the MSSQL instance using connection string or password authentication via `TriggerAuthentication` configuration.\n\n**Connection string authentication:**\n\n- `connectionString` - The connection string for the MSSQL instance.\n\n**Password authentication:**\n\n- `host` - The hostname of the MSSQL instance endpoint.\n- `port` - The port number of the MSSQL instance endpoint. (default 1433)\n- `database` - The name of the database to query.\n- `username` - The username credential for connecting to the MSSQL instance.\n- `password` - The password credential for connecting to the MSSQL instance.\n\n### Example\n\nThe following is an example of how to deploy a scaled object with the `mssql` scale trigger that uses `TriggerAuthentication` and a connection string.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mssql-secrets\ntype: Opaque\ndata:\n  mssql-connection-string: U2VydmVyPWV4YW1wbGUuZGF0YWJhc2Uud2luZG93cy5uZXQ7cG9ydD0xNDMzO0RhdGFiYXNlPUFkdmVudHVyZVdvcmtzO1BlcnNpc3QgU2VjdXJpdHkgSW5mbz1GYWxzZTtVc2VyIElEPXVzZXIxO1Bhc3N3b3JkPVBhc3N3b3JkIzE7RW5jcnlwdD1UcnVlO1RydXN0U2VydmVyQ2VydGlmaWNhdGU9RmFsc2U7 # base64 encoded value of MSSQL connectionString of format \"Server=example.database.windows.net;port=1433;Database=AdventureWorks;Persist Security Info=False;User ID=user1;Password=Password#1;Encrypt=True;TrustServerCertificate=False;\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mssql-secret\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mssql-secrets\n    key: mssql-connection-string\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mssql-scaledobject\nspec:\n  scaleTargetRef:\n    name: consumer # e.g. the name of the resource to scale\n  triggers:\n  - type: mssql\n    metadata:\n      targetValue: 1\n      query: \"SELECT COUNT(*) FROM backlog WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mssql-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/mysql.md",
    "content": "+++\ntitle = \"MySQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on MySQL query result.\"\ngo_file = \"mysql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `mysql` trigger that scales based on result of MySQL query.\n\nThe trigger always requires the following information:\n\n- `query` - A MySQL query that should return single numeric value.\n- `queryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [MySQL documentation](https://dev.mysql.com/doc/refman/8.4/en/comparison-operators.html#function_coalesce) for more information on the `COALESCE` function.\n\nTo provide information about how to connect to MySQL you can provide:\n\n- `connectionStringFromEnv` - MySQL connection string that should point to environment variable with valid value.\n\nOr provide more detailed information:\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `passwordFromEnv` - Password for the given user, this should be blank (no password) or point to an environment variable with the password.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host of the MySQL server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the MySQL server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using connection string or password authentication.\n\n**Connection String Authentication:**\n\n- `connectionString` - Connection string for MySQL database.\n\n**Password Authentication:**\n\n- `host` - The host of the MySQL server.\n- `port` - The port of the MySQL server.\n- `dbName` - Name of the database.\n- `username` - Username to authenticate with to MySQL database.\n- `password` - Password for configured user to login to MySQL database.\nvariables.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `mysql` scale trigger which uses `TriggerAuthentication`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: mysql-secrets\n  namespace: my-project\ntype: Opaque\ndata:\n  mysql_conn_str: dXNlckB0Y3AobXlzcWw6MzMwNikvc3RhdHNfZGI= # base64 encoded value of mysql connectionString of format user:password@tcp(mysql:3306)/stats_db\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-mysql-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: connectionString\n    name: mysql-secrets\n    key: mysql_conn_str\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: mysql-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: worker\n  triggers:\n  - type: mysql\n    metadata:\n      queryValue: \"4.4\"\n      activationQueryValue: \"5.4\"\n      query: \"SELECT CEIL(COUNT(*) / 6) FROM task_instance WHERE state='running' OR state='queued'\"\n    authenticationRef:\n      name: keda-trigger-auth-mysql-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/nats-jetstream.md",
    "content": "+++\ntitle = \"NATS JetStream\"\nlayout = \"scaler\"\navailability = \"v2.8+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS JetStream.\"\ngo_file = \"nats_jetstream_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `nats-jetstream` trigger for NATS JetStream.\n\n```yaml\ntriggers:\n- type: nats-jetstream\n  metadata:\n    natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n    account: \"$G\"\n    stream: \"mystream\"\n    consumer: \"pull_consumer\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"15\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the NATS server monitoring endpoint.\n- `account` - Name of the NATS account. \"$G\" is default when no account is configured.\n- `stream` - Name of the JS stream within the account.\n- `consumer` - Name of the consumer for a given stream.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS server monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nNot supported yet.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: nats-jetstream-scaledobject\n  namespace: nats-jetstream\nspec:\n  pollingInterval: 3   # Optional. Default: 30 seconds\n  cooldownPeriod: 10   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 2   # Optional. Default: 100\n  scaleTargetRef:\n    name: sub\n  triggers:\n  - type: nats-jetstream\n    metadata:\n      natsServerMonitoringEndpoint: \"nats.nats.svc.cluster.local:8222\"\n      account: \"$G\"\n      stream: \"mystream\"\n      consumer: \"pull_consumer\"\n      lagThreshold: \"10\"\n      activationLagThreshold: \"15\"\n      useHttps: \"false\"\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/nats-streaming.md",
    "content": "+++\ntitle = \"NATS Streaming\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on NATS Streaming.\"\ngo_file = \"stan_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `stan` trigger for NATS Streaming.\n\n```yaml\ntriggers:\n- type: stan\n  metadata:\n    natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n    queueGroup: \"grp1\"\n    durableName: \"ImDurable\"\n    subject: \"Test\"\n    lagThreshold: \"10\"\n    activationLagThreshold: \"5\"\n    useHttps: \"false\"\n```\n\n**Parameter list:**\n\n- `natsServerMonitoringEndpoint` - Location of the Nats Streaming monitoring endpoint.\n- `queueGroup` - Name of queue group of the subscribers.\n- `durableName` - Name of durability used by subscribers.\n- `subject` - Name of the channel.\n- `lagThreshold` - Average target value to trigger scaling actions.\n- `activationLagThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `useHttps` - Specifies if the NATS Streaming monitoring endpoint is using HTTPS. (Default: `false`, Optional)\n\n### Authentication Parameters\n\nYou can authenticate with the NATS streaming server by using connection string authentication via `TriggerAuthentication` configuration.\n\n- `natsServerMonitoringEndpoint` - Location of the NATS Streaming monitoring endpoint.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      natsServerMonitoringEndpoint: \"stan-nats-ss.stan.svc.cluster.local:8222\"\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n      useHttps: \"false\"\n```\n#### Example with TriggerAuthentication:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: stan-secret\n  namespace: example\ntype: Opaque\ndata:\n  stan_endpoint: <base-64-encoded-endpoint>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-stan-secret\n  namespace: example\nspec:\n  secretTargetRef:\n  - parameter: natsServerMonitoringEndpoint\n    name: stan-secret\n    key: stan_endpoint\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: stan-scaledobject\n  namespace: example\nspec:\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30   # Optional. Default: 300 seconds\n  minReplicaCount: 0   # Optional. Default: 0\n  maxReplicaCount: 30  # Optional. Default: 100\n  scaleTargetRef:\n    name: gonuts-sub\n  triggers:\n  - type: stan\n    metadata:\n      queueGroup: \"grp1\"\n      durableName: \"ImDurable\"\n      subject: \"Test\"\n      lagThreshold: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-stan-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/new-relic.md",
    "content": "+++\ntitle = \"New Relic\"\navailability = \"2.6+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on New Relic NRQL\"\ngo_file = \"newrelic_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `new-relic` trigger that scales based on a New Relic metric.\n\n```yaml\ntriggers:\n  - type: new-relic\n    metadata:\n      # Required: Account - Subaccount to run the query on\n      account: '1234567'\n      # Required: QueryKey - Api key to connect to New Relic\n      queryKey: \"NRAK-xxxxxxxxxxxxxxxxxxxxxxxxxxx\"\n      # Optional: nrRegion - Region to query data for. Default value is US.\n      region: \"US\"\n      # Optional: noDataError - If the query returns no data should this be treated as an error. Default value is false.\n      noDataError: \"true\"\n      # Required: nrql\n      nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n      # Required: threshold\n      threshold: \"50.50\"\n      # Optional: activationThreshold - Target value for activating the scaler.\n      activationThreshold: \"20.1\"\n```\n\n**Parameter list:**\n\n- `account` - The account within New Relic that the request should be targeted against.\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n- `region` - The region to connect to for the New Relic apis. (Values: `LOCAL`, `EU`, `STAGING`, `US`, Default: `US`, Optional)\n- `noDataError` - Should queries that return nodata be treated as an error, if set to false and a query returns nodata, the result be `0`. (Values: `true`, `false`, Default: `false`, Optional)\n- `nrql` - The New Relic query that will be run to get the data requested.\n\n  NOTE: The default New Relic time range for a query is last 30 minutes, which can produce unexpected responses. To mimic the behavior of a TIMESERIES query, you need to reduce the scope to 1 minute, this can be achieved by adding `SINCE 1 MINUTE AGO` to the query.\n [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/) [official documentation](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/introduction-nrql-new-relics-query-language/)\n- `threshold` - A threshold that is used as the `targetValue` or `targetAverageValue` (depending on the trigger metric type) in the HPA configuration. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nYou can use `TriggerAuthentication` CRD to configure the authentication with a `queryKey`.\n\n**Authentication:**\n\n- `queryKey` - The API key that will be leveraged to connect to New Relic and make requests. [official documentation](https://docs.newrelic.com/docs/apis/intro-apis/new-relic-api-keys/)\n\n- `account` - The account within New Relic that the request should be targeted against. This can be used to replace the value that would be provided in the trigger.\n\n- `region` - The region to connect to for the New Relic apis. This can be used to replace the value that would be provided in the trigger.\n\n### Example\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: new-relic-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  apiKey: TlJBSy0xMjM0NTY3ODkwMTIzNDU2Nwo= # base64 encoding of the new relic api key NRAK-12345678901234567\n  account: MTIzNDU2 # base64 encoding of the new relic account number 123456\n  region: VVM= # base64 encoding of the new relic region US\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-new-relic\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: queryKey\n    name: new-relic-secret\n    key: apiKey\n  - parameter: account\n    name: new-relic-secret\n    key: account\n  - parameter: region\n    name: new-relic-secret\n    key: region\n\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: newrelic-scaledobject\n  namespace: keda\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: new-relic\n      metadata:\n        nrql: \"SELECT average(duration) from Transaction where appName='SITE'\"\n        noDataError: \"true\"\n        threshold: '1000'\n      authenticationRef:\n        name: keda-trigger-auth-new-relic\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/openstack-metric.md",
    "content": "+++\ntitle = \"OpenStack Metric\"\navailability = \"v2.3+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a threshold reached by a specific measure from OpenStack Metric API.\"\ngo_file = \"openstack_metrics_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-metric` trigger for OpenStack metrics.\n> The OpenStack metric API follows [Gnocchi](https://gnocchi.xyz/) API. Attempt to the fact that Gnocchi API is an open-source time series database embedded in OpenStack system and every parameter on OpenStack Metric API follows its patterns but you don't need to reference anything from Gnocchi. It scales based on a specific measure from a given resource metric.\nIt's highly recommended to check [Gnocchi](https://gnocchi.xyz/) docs.\n\n```yaml\ntriggers:\n- type: openstack-metric\n  metadata:\n    metricsURL: http://localhost:8041/v1/metric #required\n    metricID: 003bb589-166d-439d-8c31-cbf098d863de #required\n    aggregationMethod: \"mean\" #required\n    granularity: 300 #required (seconds)\n    threshold: \"1.250\" #required\n    activationThreshold: \"0.250\" #optional\n    timeout: 30 #optional\n```\n\n> Protocol (http or https) should always be provided when specifying URLs\n\n**Parameter list:**\n- `metricsURL` - The URL to check for the metrics API, based. It must contain the hostname, the metric port, the API version, and the resource ID. The pattern is: `http://<host>:<metric_port>/<openstack_metric_api_version>/<resource_id>/metric`.\n- `metricID` - The Id of the intended metric.\n- `aggregationMethod` - The aggregation method that will be used to calculate metrics, it must follows the configured possible metrics derived from gnocchi API like: `mean`, `min`, `max`, `std`, `sum`, `count`, the complete aggregation methods list can be found [here](https://gnocchi.xyz/rest.html#archive-policy).\n- `granularity` - The configured granularity from metric collection in seconds. it must follow the same value configured in OpenStack, but it must be counted in seconds. Sample: If you have a 5 minutes time window granularity defined, so you must input a value of 300 seconds (5*60).\n- `threshold` - The target value that, when reached, will scale the application. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Metric API.  (Default: `30`, Optional)\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The pattern is: `http://<host>:<keystone_port>/<keystone_version>/`.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-metric` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: metrics-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n      metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n      timeout: 30\n    authenticationRef:\n        name: openstack-metric-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwL3YzLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: openstack-metric-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: openstack-metric-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-metric\n    metadata:\n       metricsURL: http://localhost:8041/v1/metric\n      metricID: faf01aa5-da88-4929-905d-b83fbab46771\n      aggregationMethod: \"mean\"\n      granularity: 300\n      threshold: 1250\n    authenticationRef:\n        name: openstack-metric-appcredentials-trigger-authentication\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/openstack-swift.md",
    "content": "+++\ntitle = \"OpenStack Swift\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on the count of objects in a given OpenStack Swift container.\"\ngo_file = \"openstack_swift_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `openstack-swift` trigger for OpenStack Swift containers. It scales based on the count of objects in a given container.\n\n```yaml\ntriggers:\n- type: openstack-swift\n  metadata:\n    containerName: my-container # Required\n    swiftURL: http://localhost:8080/v1/b161dc815cd24bda84d94d9a0e73cf78  # Optional\n    objectCount: \"2\"  # Optional\n    activationObjectCount: \"5\" # Optional\n    objectPrefix: \"my-prefix\" # Optional\n    objectDelimiter: \"/\"  # Optional\n    objectLimit: \"10\" # Optional\n    onlyFiles: \"true\" # Optional\n    timeout: \"2\"  # Optional\n```\n\n> Please, always provide the protocol (http or https) when specifying URLs.\n\n**Parameter list:**\n\n- `swiftURL` - The URL to query the Swift API. If not provided, the scaler will try to find the Swift public URL for a certain region, using the OpenStack catalog, which is returned when requesting an authentication token. (Optional)\n- `containerName` - Name of Swift container in an OpenStack account.\n- `objectCount` - Average target value to trigger scaling actions. (Default: `2`, Optional)\n- `activationObjectCount` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `objectPrefix` - Prefix for the object. Only objects with this prefix will be returned. Use this prefix to specify sub-paths for the objects. (Default: `\"\"`, Optional)\n- `objectDelimiter` - Delimiter for identifying the object prefix. It is the character used to split object names. (Default: `\"\"`, Optional)\n- `objectLimit` - The maximum number of objects returned by the API. By default, the Swift API only returns up to 10000 names. (Default: `\"\"`, Optional)\n- `onlyFiles` - Specifies if the scaler should be triggered only by the number of files, without considering folders. Inside a container, one can have files and folders. Folders (empty or not) are counted as objects, just as files are. If one wants to scale based on only files, this parameter must be set to `true`. (Values: `true`, `false`, Default: `false`, Optional)\n- `timeout` - The timeout, in seconds, for the HTTP client requests that will query the Swift API. (Default: `30`, Optional)\n\nFor more information about `prefix`, `delimiter`, and `limit`, please, refer to the [Object Store API](https://docs.openstack.org/api-ref/object-store/).\n\n### Authentication Parameters\n\nTo authenticate, this scaler uses tokens. Tokens are automatically retrieved by the scaler from [Keystone](https://docs.openstack.org/keystone/latest/), the official OpenStack Identity Provider. You can provide your credentials using Secrets either by using the \"password\" method or the \"application credentials\" method. Both cases use `TriggerAuthentication`.\n\n#### Password\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `userID` - The OpenStack project user ID.\n- `password` - The password for the provided user.\n- `projectID` - The OpenStack project ID.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n#### Application Credentials\n\n- `authURL` - The Keystone authentication URL. The scaler supports only Keystone v3. You shouldn't include the `/v3` parameter in your URL path. This is done automatically by the scaler.\n- `appCredentialID` - The Application Credential ID.\n- `appCredentialSecret` - The Application Credential secret.\n- `regionName` - The OpenStack region name where the Swift service is available. This parameter is not required and is used only when the `swiftURL` is not provided to the scaler. If the region name is not provided, it will look for the first Swift public URL available in the OpenStack catalog.\n\n### Example\n\n#### Password method\n\nHere is an example of how to deploy a scaled object with the `openstack-swift` scale trigger which uses `TriggerAuthentication` and the Password method from above.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-password\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  userID: MWYwYzI3ODFiNDExNGQxM2E0NGI4ODk4Zjg1MzQwYmU=\n  password: YWRtaW4=\n  projectID: YjE2MWRjNTE4Y2QyNGJkYTg0ZDk0ZDlhMGU3M2ZjODc=\n  regionName: Y2FsaWZvcm5pYS0x\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-password-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-password\n    key: authURL\n  - parameter: userID\n    name: openstack-secret-password\n    key: userID\n  - parameter: password\n    name: openstack-secret-password\n    key: password\n  - parameter: projectID\n    name: openstack-secret-password\n    key: projectID\n  - parameter: regionName\n    name: openstack-secret-password\n    key: regionName\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      containerName: my-container\n      objectCount: \"1\"\n      onlyFiles: \"true\"\n    authenticationRef:\n        name: swift-password-trigger-authentication\n```\n\n#### Application Credentials method\n\nYou can also use the Application Credentials method.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: openstack-secret-appcredentials\n  namespace: default\ntype: Opaque\ndata:\n  authURL: aHR0cDovL2xvY2FsaG9zdDo1MDAwLw==\n  appCredentialID: OWYyY2UyYWRlYmFkNGQxNzg0NTgwZjE5ZTljMTExZTQ=\n  appCredentialSecret: LVdSbFJBZW9sMm91Z3VmZzNEVlBqcll6aU9za1pkZ3c4Y180XzRFU1pZREloT0RmajJkOHg0dU5yb3NudVIzWmxDVTZNLTVDT3R5NDFJX3M5R1N5Wnc=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: swift-appcredentials-trigger-authentication\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: authURL\n    name: openstack-secret-appcredentials\n    key: authURL\n  - parameter: appCredentialID\n    name: openstack-secret-appcredentials\n    key: appCredentialID\n  - parameter: appCredentialSecret\n    name: openstack-secret-appcredentials\n    key: appCredentialSecret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: swift-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  pollingInterval: 10\n  cooldownPeriod: 10\n  minReplicaCount: 0\n  triggers:\n  - type: openstack-swift\n    metadata:\n      swiftURL: http://localhost:8080/v1/AUTH_b161dc518cd24bda84d94d9a0e73fc87\n      containerName: my-container\n      objectCount: \"1\"\n    authenticationRef:\n        name: swift-appcredentials-trigger-authentication\n```"
  },
  {
    "path": "content/docs/2.9/scalers/postgresql.md",
    "content": "+++\ntitle = \"PostgreSQL\"\navailability = \"v1.2+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on a PostgreSQL query.\"\ngo_file = \"postgresql_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `postgresql` trigger that scales based on a PostgreSQL query\n\nThe PostgreSQL scaler allows for two connection options:\n\nA user can offer a full connection string\n(often in the form of an environment variable secret)\n\n- `connectionFromEnv` - PostgreSQL connection string that should point to environment variable with valid value.\n\nAlternatively, a user can specify individual\narguments (host, userName, password, etc.), and the scaler will form a connection string\ninternally.\n\n- `host:` - Service URL to postgresql. Note that you should use a full svc URL as KEDA will need to contact postgresql from a different namespace.\n- `userName:` - Username for postgresql user.\n- `passwordFromEnv` Password for postgresql user.\n- `port` - Postgresql port.\n- `dbName` - Postgresql Database name.\n- `sslmode` - SSL policy for communicating with database.\n\nFinally, a user inserts a query that returns the desired value.\n\n- `query` - What query to poll postgresql with. Query must return an integer.\n- `targetQueryValue` - A threshold that is used as `targetValue` or `targetAverageValue` (depending on the trigger metric type) in HPA. (This value can be a float)\n- `activationTargetQueryValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on either the connection string if set or the db name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n\n> Note that the query must return a single integer value. If the query has a possibility of returning `null`, a default value can be set using the `COALESCE` function. For example, `SELECT COALESCE(column_name, 0) FROM table_name;`. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) for more information on the `COALESCE` function.\n\nThis is an example of using a full connection string with `AIRFLOW_CONN_AIRFLOW_DB` set as `postgresql://test@localhost`:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"1.1\"\n    activationTargetQueryValue: \"5\"\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-postgresql---test@localhost`\n```\n\nWhile this is an example of specifying each parameter:\n\n```yaml\ntriggers:\n- type: postgresql\n  metadata:\n    userName: \"kedaUser\"\n    passwordFromEnv: PG_PASSWORD\n    host: postgres-svc.namespace.cluster.local #use the cluster-wide namespace as KEDA\n                                                #lives in a different namespace from your postgres\n    port: \"5432\"\n    dbName: test_db_name\n    sslmode: disable\n    query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n    targetQueryValue: \"2.2\"\n    metricName: backlog_process_count #optional. Generated value would be `postgresql-test_db_name`\n```\n\n### Authentication Parameters\n\nYou can authenticate by using a password or store the password within the connectionString.\n\n**Connection String Authentication:**\n\n- `connection` - Connection string for PostgreSQL database.\n\n**Password Authentication:**\n\n- `host` - Service URL to PostgreSQL. Note that you should use a fully qualified URL (including the namespace) as KEDA will need to contact PostgreSQL from a different namespace.\n- `userName` - Username for PostgreSQL user.\n- `password` Password for configured user to login to PostgreSQL database variables.\n- `port` - PostgreSQL port.\n- `dbName` - PostgreSQL Database name.\n- `sslmode` - SSL policy for communicating with database.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: airflow-worker\nspec:\n  scaleTargetRef:\n    name: airflow-worker\n  pollingInterval: 10   # Optional. Default: 30 seconds\n  cooldownPeriod: 30    # Optional. Default: 300 seconds\n  maxReplicaCount: 10   # Optional. Default: 100\n  triggers:\n    - type: postgresql\n      metadata:\n        connectionFromEnv: AIRFLOW_CONN_AIRFLOW_DB\n        query: \"SELECT ceil(COUNT(*)::decimal / 16) FROM task_instance WHERE state='running' OR state='queued';\"\n        targetQueryValue: 1\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/predictkube.md",
    "content": "+++\ntitle = \"Predictkube\"\navailability = \"v2.6+\"\nmaintainer = \"Dysnix\"\ndescription = \"AI-based predictive scaling based on Prometheus metrics & PredictKube SaaS.\"\ngo_file = \"predictkube_scaler\"\n+++\n\nPredictKube is an open-source project with the SAAS part consisting of an AI model that requires API to connect to the project for the main functions of predicting and scaling.\n\nTo make our AI model access your data and make a prediction based on it, please use the API key we'll send to your e-mail.\n\nReview our [Privacy Policy](https://predictkube.com/privacy-policy) to see how your data circulates in and out PredictKube.\n\n### Trigger Specification\n\nThis specification describes the `predictkube` trigger that scales based on a predicting load based on `prometheus` metrics.\n\n```yaml\ntriggers:\n- type: predictkube\n  metadata:\n    # Required fields:\n    predictHorizon: \"2h\"\n    historyTimeWindow: \"7d\"\n    prometheusAddress: http://<prometheus-host>:9090\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n    queryStep: \"2m\"\n    threshold: '100.50'\n    activationThreshold: '50.1'\n```\n\n**Parameter list:**\n\n- `predictHorizon` - Prediction time interval. It is usually equal to the cool-down period of your application.\n- `historyTimeWindow` - Time range for which to request metrics from Prometheus. We recommend using minimum 7-14 days time window as historical data.\n- `prometheusAddress` - Address of Prometheus server.\n- `query` - Predict the query that will yield the value for the scaler to compare against the `threshold`. The query must return a vector/scalar single element response.\n- `queryStep` - The maximum time between two slices within the boundaries for QML range query, used in the query.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold`- Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n\n### Authentication Parameters\n\nPredictkube Scaler supports one type of authentication - authentication by API key.\nPrometheus used in Predictkube Scaler supports all authentication methods that are available in Prometheus Scaler.\n\n**Auth gateway based authentication:**\n\n- `apiKey` - API key previously issued for this tenant. You can get your API key by clicking on any **GET API KEY** button on the [website of PredictKube](https://predictkube.com/)\n\n### Example\n\n```yaml\n---\napiVersion: v1\nkind: Secret\nmetadata:\n  name: predictkube-secrets\n  namespace: some-namespace\ntype: Opaque\ndata:\n  apiKey: # Required: base64 encoded value of PredictKube apiKey\n  bearerToken: \"BEARER_TOKEN\" # Optional: bearer authentication for Prometheus\n  ca: \"CUSTOM_CA_CERT\" # Optional: certificate authority file for TLS client authentication for Prometheus\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-predictkube-secret\n  namespace: some-namespace\nspec:\n  secretTargetRef:\n    # Required: API key for your predictkube account\n  - parameter: apiKey\n    name: predictkube-secrets\n    key: apiKey\n    # Optional: might be required if you're using bearer auth for Promethrus\n  - parameter: bearerToken\n    name: keda-prom-secret\n    key: bearerToken\n    # Optional: might be required if you're using a custom CA for Promethrus\n  - parameter: ca\n    name: keda-prom-secret\n    key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: predictkube-scaledobject\n  namespace: some-namespace\nspec:\n  scaleTargetRef:\n    name: my-deployment\n    kind: StatefulSet\n  pollingInterval: 30\n  cooldownPeriod: 7200\n  minReplicaCount: 3\n  maxReplicaCount: 50\n  triggers:\n  - type: predictkube\n    metadata:\n      predictHorizon: \"2h\"\n      historyTimeWindow: \"7d\"\n      prometheusAddress: http://<prometheus-host>:9090\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n      queryStep: \"2m\" # Note: query step duration for range prometheus queries\n      threshold: \"100\"\n      authModes: \"bearer\" # might be required if you're using bearer auth for Promethrus\n    authenticationRef:\n      name: keda-trigger-auth-predictkube-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/prometheus.md",
    "content": "+++\ntitle = \"Prometheus\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Prometheus.\"\ngo_file = \"prometheus_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `prometheus` trigger that scales based on a Prometheus.\n\n```yaml\ntriggers:\n- type: prometheus\n  metadata:\n    # Required fields:\n    serverAddress: http://<prometheus-host>:9090\n    metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total`\n    query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m])) # Note: query must return a vector/scalar single element response\n    threshold: '100.50'\n    activationThreshold: '5.5'\n    # Optional fields:\n    namespace: example-namespace  # for namespaced queries, eg. Thanos\n    cortexOrgID: my-org # Optional. X-Scope-OrgID header for Cortex.\n    ignoreNullValues: \"false\" # Default is `true`, which means ignoring the empty value list from Prometheus. Set to `false` the scaler will return error when Prometheus target is lost\n    unsafeSsl: \"false\" #  Default is `false`, Used for skipping certificate check when having self-signed certs for Prometheus endpoint\n```\n\n**Parameter list:**\n\n- `serverAddress` - Address of Prometheus server. If using VictoriaMetrics cluster version, set full URL to Prometheus querying API, e.g. `http://<vmselect>:8481/select/0/prometheus`\n- `metricName` - Name to identify the Metric in the external.metrics.k8s.io API. If using more than one trigger it is required that all `metricName`(s) be unique.\n- `query` - Query to run.\n- `threshold` - Value to start scaling for. (This value can be a float)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `namespace` - A namespace that should be used for namespaced queries. These are required by some highly available Prometheus setups, such as [Thanos](https://thanos.io). (Optional)\n- `cortexOrgID` - The `X-Scope-OrgID` header to query multi tenant [Cortex](https://cortexmetrics.io/) or [Mimir](https://grafana.com/oss/mimir/). (Optional)\n- `ignoreNullValues` - Value to reporting error when Prometheus target is lost (Values: `true`,`false`, Default: `true`, Optional)\n- `unsafeSsl` - Used for skipping certificate check e.g: using self-signed certs  (Values: `true`,`false`, Default: `false`, Optional)\n\n### Authentication Parameters\n\nPrometheus Scaler supports three types of authentication - bearer authentication, basic authentication and TLS authentication.\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. It is possible to specify multiple authentication types i.e. `authModes: \"tls,basic\"` Specify `authModes` and other trigger parameters along with secret credentials in `TriggerAuthentication` as mentioned below:\n\n**Bearer authentication:**\n- `authModes`: It must contain `bearer` in case of Bearer Authentication. Specify this in trigger configuration.\n- `bearerToken`: The token needed for authentication. This is a required field.\n\n**Basic authentication:**\n- `authModes`: It must contain `basic` in case of Basic Authentication. Specify this in trigger configuration.\n- `username` - This is a required field. Provide the username to be used for basic authentication.\n- `password` - Provide the password to be used for authentication. For convenience, this has been marked optional, because many applications implement basic auth with a username as apikey and password as empty.\n\n**TLS authentication:**\n- `authModes`: It must contain `tls` in case of TLS Authentication. Specify this in trigger configuration.\n- `ca` - Certificate authority file for TLS client authentication.\n- `cert` - Certificate for client authentication. This is a required field.\n- `key` - Key for client authentication. Optional. This is a required field.\n\n> 💡 **NOTE:**It's also possible to set the CA certificate regardless of the selected `authModes` (also without any authentication). This might be useful if you are using an enterprise CA.\n\n### Example\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-deployment\n  triggers:\n  - type: prometheus\n    metadata:\n      serverAddress: http://<prometheus-host>:9090\n      metricName: http_requests_total\n      threshold: '100'\n      query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n```\n\nHere is an example of a prometheus scaler with Bearer Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  bearerToken: \"BEARER_TOKEN\"\n  ca: \"CUSTOM_CA_CERT\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: bearerToken\n      name: keda-prom-secret\n      key: bearerToken\n      # might be required if you're using a custom CA\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"bearer\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  username: \"dXNlcm5hbWUK\" # Must be base64\n  password: \"cGFzc3dvcmQK\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\n\nHere is an example of a prometheus scaler with TLS Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n\nHere is an example of a prometheus scaler with TLS and Basic Authentication, define the `Secret` and `TriggerAuthentication` as follows\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-prom-secret\n  namespace: default\ndata:\n  cert: \"cert\"\n  key: \"key\"\n  ca: \"ca\"\n  username: \"username\"\n  password: \"password\"\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-prom-creds\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: cert\n      name: keda-prom-secret\n      key: cert\n    - parameter: key\n      name: keda-prom-secret\n      key: key\n    - parameter: ca\n      name: keda-prom-secret\n      key: ca\n    - parameter: username\n      name: keda-prom-secret\n      key: username\n    - parameter: password\n      name: keda-prom-secret\n      key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: prometheus-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: dummy\nspec:\n  maxReplicaCount: 12\n  scaleTargetRef:\n    name: dummy\n  triggers:\n    - type: prometheus\n      metadata:\n        serverAddress: http://<prometheus-host>:9090\n        metricName: http_requests_total\n        threshold: '100'\n        query: sum(rate(http_requests_total{deployment=\"my-deployment\"}[2m]))\n        authModes: \"tls,basic\"\n      authenticationRef:\n        name: keda-prom-creds\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/pulsar.md",
    "content": "+++\ntitle = \"Apache Pulsar\"\navailability = \"v2.8\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on an Apache Pulsar topic subscription.\"\ngo_file = \"pulsar_scaler\"\nlayout = \"scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `pulsar` trigger for an Apache Pulsar topic.\n\n```yaml\ntriggers:\n- type: pulsar\n  metadata:\n    adminURL: http://localhost:80\n    topic: persistent://public/default/my-topic\n    isPartitionedTopic: false\n    subscription: sub1\n    msgBacklogThreshold: '5'\n    activationMsgBacklogThreshold: '2'\n    authModes: \"\"\n```\n\n**Parameter list:**\n\n- `adminURL` - Stats URL of the admin API for your topic.\n- `topic` - Pulsar topic. format of `persistent://{tenant}/{namespace}/{topicName}`\n- `isPartitionedTopic` - Whether the `topic` is partitioned. When `true`, the `msgBacklogThreshold` will be the cumulative subscription backlog across partitions. (default: `false`, Optional)\n- `subscription` - Name of the topic subscription\n- `msgBacklogThreshold` - Average target value to trigger scaling actions. (default: 10)\n- `activationMsgBacklogThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `authModes` - a comma separated list of authentication modes to use. (Values: `bearer`, `tls`,`basic`, Default: `\"\"`, Optional, `tls,bearer` or `tls,basic` are valid combinations and would indicate mutual TLS to secure the connection and then `bearer` or `basic` headers should be added to the HTTP request)\n\n### Authentication Parameters\n\nThe authentication is defined in `authModes`. The associated configuration parameters are specified in the `TriggerAuthentication` spec.  \n\n**Bearer Auth**\n\nWhen configuring Bearer Authentication (Token Auth), configure the following:\n\n- `bearerToken`: This token will be sent as a header in the form `Authorization: Bearer <token>`. \n\n**Basic Auth**\nWhen configuring Basic Authentication, configure the following:\n\n- `username`: the username\n- `password`: the password (optional)\n\n**TLS:**\n\nWhen configuring mutual TLS authentication, configure the following:\n\n- `ca`: The trusted root Certificate authority used to validate the server's certificate.\n- `cert`: Certificate for client authentication.\n- `key`: Key for client authentication. \n\n\n### TLS with custom CA Certificates\n\nWhen configuring a trusted root CA that is not well known, it is sufficient to specify the `ca` field on the `TriggerAuthentication` resource. See [Bearer Token with TLS via custom trusted CA Certificate](#bearer-token-with-tls-via-custom-trusted-ca-certificate) for an example.\n\nBefore 2.9.0, it was necessary to configure `tls: enable` on the `ScaledObject`. That was removed in a backwards compatible way, so you can remove that field now.\n\n### Examples\n\n#### No Authentication and No TLS\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      adminURL: http://localhost:80\n      topic: persistent://public/default/my-topic\n      isPartitionedTopic: false\n      subscription: sub1\n      msgBacklogThreshold: '5'\n```\n\n#### Only Mutual TLS Authentication\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your ca>\n  cert: <your cert>\n  key: <your key>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: cert\n    name: keda-pulsar-secrets\n    key: cert\n  - parameter: key\n    name: keda-pulsar-secrets\n    key: key\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"tls\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Bearer Token with TLS via custom trusted CA Certificate\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  ca: <your self-signed root CA>\n  token: <your token>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: ca\n    name: keda-pulsar-secrets\n    key: ca\n  - parameter: bearerToken\n    name: keda-pulsar-secrets\n    key: token\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://localhost:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n\n#### Basic Auth with TLS Relying on Well Known Root CA\n\nIn order to enable Pulsar's Token Authentication feature, you can use the following example. Note that this example\nalso utilizes a custom CA Certificate for TLS support. Because TLS Authentication is not used in this example, the\n`authModes` field only has `bearer`.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-pulsar-secrets\n  namespace: default\ndata:\n  username: <your username>\n  password: <your password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-pulsar-credential\n  namespace: default\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: keda-pulsar-secrets\n    key: admin\n  - parameter: password\n    name: keda-pulsar-secrets\n    key: password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: pulsar-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: pulsar-consumer\n  pollingInterval: 30\n  triggers:\n  - type: pulsar\n    metadata:\n      authModes: \"bearer\"\n      adminURL: https://pulsar.com:8443\n      topic: persistent://public/default/my-topic\n      subscription: sub1\n      msgBacklogThreshold: '5'\n    authenticationRef:\n      name:  keda-trigger-auth-pulsar-credential\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/rabbitmq-queue.md",
    "content": "+++\ntitle = \"RabbitMQ Queue\"\navailability = \"v1.0+\"\nmaintainer = \"Microsoft\"\ndescription = \"Scale applications based on RabbitMQ Queue.\"\ngo_file = \"rabbitmq_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `rabbitmq` trigger for RabbitMQ Queue.\n\n```yaml\ntriggers:\n- type: rabbitmq\n  metadata:\n    host: amqp://localhost:5672/vhost # Optional. If not specified, it must be done by using TriggerAuthentication.\n    protocol: auto # Optional. Specifies protocol to use, either amqp or http, or auto to autodetect based on the `host` value. Default value is auto.\n    mode: QueueLength # QueueLength or MessageRate\n    value: \"100.50\" # message backlog or publish/sec. target per instance\n    activationValue: \"10.5\" # Optional. Activation threshold\n    queueName: testqueue\n    vhostName: / # Optional. If not specified, use the vhost in the `host` connection string.\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    hostFromEnv: RABBITMQ_HOST # Optional. You can use this instead of `host` parameter\n```\n\n**Parameter list:**\n\n- `host` - Host of RabbitMQ with format `<protocol>://<host>:<port>/vhost`. The resolved host should follow a format like `amqp://guest:password@localhost:5672/vhost` or `http://guest:password@localhost:15672/vhost`. When using a username/password consider using `hostFromEnv` or a TriggerAuthentication.\n- `queueName` - Name of the queue to read message from.\n- `mode` - QueueLength to trigger on number of messages in the queue. MessageRate to trigger on the publish rate into the queue. (Values: `QueueLength`, `MessageRate`)\n- `value` - Message backlog or Publish/sec. rate to trigger on. (This value can be a float when `mode: MessageRate`)\n- `activationValue` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds).(Default: `0`, Optional, This value can be a float)\n- `protocol` - Protocol to be used for communication. (Values: `auto`, `http`, `amqp`, Default: `auto`, Optional)\n- `vhostName` - Vhost to use for the connection, overrides any vhost set in the connection string from `host`/`hostFromEnv`. (Optional)\n- `queueLength` - DEPRECATED! Use `mode: QueueLength` and `value: ##` instead. Target value for queue length passed to the scaler. Example: if one pod can handle 10 messages, set the queue length target to 10. If the actual number of messages in the queue is 30, the scaler scales to 3 pods. Default is 20 unless `publishRate` is specified, in which case `queueLength` is disabled for this trigger.\n- `useRegex` - This parameter allows to use regex (in `queueName` parameter) to select queue instead of full name. (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n- `pageSize` - This parameter allows setting page size. (Default: `100`, Optional, Only applies when `useRegex` is `true`)\n- `operation` - Operation that will be applied to compute the number of messages in case of `useRegex` enabled. Either `sum` (default),`max`, or `avg`. (Optional)\n- `metricName` - Name to assign to the metric. If not set KEDA will generate a name based on the queue name. If using more than one trigger it is required that all metricNames be unique. (Optional)\n- `timeout` - Timeout **for this specific trigger**. This value will override the value defined in `KEDA_HTTP_DEFAULT_TIMEOUT`. (Optional, Only applies to hosts that use the `http` protocol)\n- `excludeUnacknowledged` - Set to `true` to specify that the `QueueLength` value should exclude unacknowledged messages (Ready messages only). (Values: `true`, `false`, Default: `false`, Optional, Only applies to hosts that use the `http` protocol)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `hostFromEnv` - The host and port of the RabbitMQ server, similar to `host`, but reads it from an environment variable on the scale target.\n\n> 💡 **Note:** `host`/`hostFromEnv` has an optional vhost name after the host slash which will be used to scope API request.\n\n> 💡 **Note:** When using `host`/`hostFromEnv` or TriggerAuthentication, the supplied password cannot contain special characters.\n\n> 💡 **Note:** `mode: MessageRate` requires protocol `http`.\n\n> 💡 **Note:** `useRegex: \"true\"` requires protocol `http`.\n\n> ⚠ **Important:** if you have unacknowledged messages and want to have these counted for the scaling to happen, make sure to utilize the `http` REST API interface which allows for these to be counted.\n\n> ⚠ **Important:** If scaling against both is desired then the `ScaledObject` should have two triggers, one for `mode: QueueLength` and the other for `mode: MessageRate`. HPA will scale based on the largest result considering each of the two triggers independently.\n\n### Authentication Parameters\n\nTriggerAuthentication CRD is used to connect and authenticate to RabbitMQ:\n\n- For AMQP, the URI should look similar to `amqp://guest:password@localhost:5672/vhost`.\n- For HTTP, the URI should look similar to `http://guest:password@localhost:15672/vhost`.\n\n> See the [RabbitMQ Ports](https://www.rabbitmq.com/networking.html#ports) section for more details on how to configure the ports.\n\n### Example\n\n#### AMQP protocol:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <AMQP URI connection string> # base64 encoded value of format amqp://guest:password@localhost:5672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: amqp\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n      metricName: custom-testqueue #optional. Generated value would be `rabbitmq-custom-testqueue`\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`MessageRate` and `QueueLength`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: QueueLength\n      value: \"20\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: testqueue\n      mode: MessageRate\n      value: \"100\"\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n\n#### HTTP protocol (`QueueLength`) and using regex (`useRegex`):\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: keda-rabbitmq-secret\ndata:\n  host: <HTTP API endpoint> # base64 encoded value of format http://guest:password@localhost:15672/vhost\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-rabbitmq-conn\n  namespace: default\nspec:\n  secretTargetRef:\n    - parameter: host\n      name: keda-rabbitmq-secret\n      key: host\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: rabbitmq-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: rabbitmq-deployment\n  triggers:\n  - type: rabbitmq\n    metadata:\n      protocol: http\n      queueName: ^.*incoming$\n      mode: QueueLength\n      value: \"20\"\n      useRegex: \"true\"\n      operation: max\n    authenticationRef:\n      name: keda-trigger-auth-rabbitmq-conn\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/redis-cluster-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Cluster topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-cluster` trigger that scales based on the length of a list in a Redis Cluster.\n\n```yaml\ntriggers:\n- type: redis-cluster\n  metadata:\n    addresses: localhost:6379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Cluster nodes.\n- `hosts` - Comma separated list of hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Cluster nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Cluster nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Cluster nodes. If specified, the `hosts` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-cluster` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-cluster\n    metadata:\n      addresses: node1:6379, node2:6379, node3:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/redis-cluster-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Cluster)\"\navailability = \"v2.1+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Cluster topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-cluster-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports Redis Cluster topology.\n\n\n```yaml\ntriggers:\n- type: redis-cluster-streams\n  metadata:\n    addresses: localhost:6379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"6379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Cluster nodes in the format `host:port` for example `node1:6379, node2:6379, node3:6379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Cluster nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Cluster nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Cluster nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Cluster nodes. The resolved hosts should follow a format like `node1:6379, node2:6379, node3:6379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Cluster nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Cluster nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-cluster-streams\n      metadata:\n        address: node1:6379, node2:6379, node3:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/redis-lists.md",
    "content": "+++\ntitle = \"Redis Lists\"\navailability = \"v1.0+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Lists.\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis` trigger that scales based on the length of a list in Redis.\n\n```yaml\ntriggers:\n- type: redis\n  metadata:\n    address: localhost:6379 # Format must be host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_HOST # Optional. You can use this instead of `address` parameter\n```\n\n**Parameter list:**\n\n- `address` - The host and port of the Redis server.\n- `host` - The host of the Redis server. Alternative to `address` and requires `port` to be configured as well.\n- `port` - The port of the Redis server. Alternative to `address` and requires `host` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n- `databaseIndex` - Index of Redis database to use. If not specified, the default value is 0.\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a username (optional) and password.\n\n**Connection Authentication:**\n\n- `address` - The hostname and port for the Redis server (host:port format).\n- `host` - The hostname of the Redis server. If specified, the `port` should also be specified.\n- `port` - The port of the Redis server. If specified, the `host` should also be specified.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis\n    metadata:\n      address: localhost:6379\n      listName: mylist\n      listLength: \"10\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/redis-sentinel-lists.md",
    "content": "+++\ntitle = \"Redis Lists (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Lists scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `redis-sentinel` trigger that scales based on the length of a list in a Redis Sentinel setup.\n\n```yaml\ntriggers:\n- type: redis-sentinel\n  metadata:\n    addresses: localhost:26379 # Comma separated list of the format host:port\n    usernameFromEnv: REDIS_USERNAME # optional\n    passwordFromEnv: REDIS_PASSWORD # optional\n    sentinelUsernameFromEnv: REDIS_SENTINEL_USERNAME # optional\n    sentinelPasswordFromEnv: REDIS_SENTINEL_PASSWORD # optional\n    sentinelMasterFromEnv: REDIS_SENTINEL_MASTER # optional\n    listName: mylist # Required\n    listLength: \"5\" # Required\n    activationListLength: \"5\" # optional\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of the Redis Sentinel nodes.\n- `hosts` - Comma separated list of hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `ports` to be configured as well.\n- `ports` - Comma separated list of corresponding ports for the hosts of the Redis Sentinel nodes. Alternative to `addresses` and requires `hosts` to be configured as well.\n- `usernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis server.\n- `passwordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis server.\n  - Both the hostname, username and password fields need to be set to the names of the environment variables in the target deployment that contain the host name, username and password respectively.\n- `sentinelUsernameFromEnv` - Environment variable to read the authentication username from to authenticate with the Redis Sentinel server.\n- `sentinelPasswordFromEnv` - Environment variable to read the authentication password from to authenticate with the Redis Sentinel server.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `listName` - Name of the Redis List that you want to monitor.\n- `listLength` - Average target value to trigger scaling actions.\n- `activationListLength` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `enableTLS` - Allow a connection to a redis queue using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and their respective ports of the Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of the Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nYou can authenticate by using a password.\n\n**Connection Authentication:**\n\n- `addresses` - Comma separated list of host:port format.\n- `hosts` - Comma separated list of hostname of the Redis Sentinel nodes. If specified, the `ports` should also be specified.\n- `ports` - Comma separated list of ports of the Redis Sentinel nodes. If specified, the `hosts` should also be specified.\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n\n**Authentication:**\n\n- `username` - Redis username to authenticate with.\n- `password` - Redis password to authenticate with.\n\n**Sentinel Authentication:**\n\n- `sentinelUsername` - Redis Sentinel username to authenticate with.\n- `sentinelPassword` - Redis Sentinel password to authenticate with.\n\n\n### Example\n\nHere is an example of how to deploy a scaled object with the `redis-sentinel` scale trigger which uses `TriggerAuthentication`.\n\nYou can also provide the `usernameFromEnv` and `passwordFromEnv` on the `ScaledObject` directly.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: votes-db-secret\n  namespace: my-project\ntype: Opaque\ndata:\n  redis_username: YWRtaW4=\n  redis_password: YWRtaW4=\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-redis-secret\n  namespace: my-project\nspec:\n  secretTargetRef:\n  - parameter: username\n    name: votes-db-secret\n    key: redis_username\n  - parameter: password\n    name: votes-db-secret\n    key: redis_password\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-scaledobject\n  namespace: my-project\nspec:\n  scaleTargetRef:\n    name: votes\n  triggers:\n  - type: redis-sentinel\n    metadata:\n      addresses: node1:26379, node2:26379, node3:26379\n      listName: mylist\n      listLength: \"10\"\n      sentinelMaster: \"mymaster\"\n    authenticationRef:\n      name: keda-trigger-auth-redis-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/redis-sentinel-streams.md",
    "content": "+++\ntitle = \"Redis Streams (supports Redis Sentinel)\"\navailability = \"v2.5+\"\nmaintainer = \"Community\"\ndescription = \"Redis Streams scaler with support for Redis Sentinel topology\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-sentinel-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream and supports a Redis Sentinel setup.\n\n\n```yaml\ntriggers:\n- type: redis-sentinel-streams\n  metadata:\n    addresses: localhost:26379 # Required if hosts and ports are not provided. Format - comma separated list of host:port\n    hosts: localhost # Comma separated lists of hosts. Required if address is not provided\n    ports: \"26379\" # Comma separated lists of ports. Required if addresses are not provided and hosts has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressesFromEnv: REDIS_ADDRESSES # Optional. You can use this instead of `addresses` parameter\n    hostsFromEnv: REDIS_HOSTS # Optional. You can use this instead of `hosts` parameter\n    portsFromEnv: REDIS_PORTS # Optional. You can use this instead of `ports` parameter\n```\n\n**Parameter list:**\n\n- `addresses` - Comma separated list of hosts and ports of Redis Sentinel nodes in the format `host:port` for example `node1:26379, node2:26379, node3:26379`.\n\n> As an alternative to the `addresses` field, the user can specify `hosts` and `ports` parameters.\n\n- `hosts` - Comma separated list of hosts of Redis Sentinel nodes.\n\n> It is not required if `addresses` has been provided.\n\n- `ports`: Comma separated list of ports for corresponding hosts of Redis Sentinel nodes.\n\n> It is only to be used along with the `hosts`/`hostsFromEnv` attribute and not required if `addresses` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `sentinelUsernameFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel username. (Optional)\n- `sentinelPasswordFromEnv` - Name of the environment variable your deployment uses to get the Redis Sentinel password. (Optional)\n\n- `sentinelMaster` - The name of the master in Sentinel to get the Redis server address for.\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressesFromEnv` - The hosts and corresponding ports of Redis Sentinel nodes, similar to `addresses`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the URLs of Redis Sentinel nodes. The resolved hosts should follow a format like `node1:26379, node2:26379, node3:26379 ...`.\n- `hostsFromEnv` - The hosts of the Redis Sentinel nodes, similar to `hosts`, but reads it from an environment variable on the scale target.\n- `portsFromEnv` - The corresponding ports for the hosts of Redis Sentinel nodes, similar to `ports`, but reads it from an environment variable on the scale target.\n- `sentinelMasterFromEnv` - The name of the master in Sentinel to get the Redis server address for, similar to `sentinelMaster`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        addressesFromEnv: REDIS_ADDRESSES\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-sentinel-streams\n      metadata:\n        address: node1:26379, node2:26379, node3:26379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n        sentinelMaster: \"mymaster\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/redis-streams.md",
    "content": "+++\ntitle = \"Redis Streams\"\navailability = \"v1.5+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Redis Streams.\"\ngo_file = \"redis_streams_scaler\"\n+++\n\n### Trigger Specification\n\nRedis 5.0 introduced [Redis Streams](https://redis.io/topics/streams-intro) which is an append-only log data structure.\n\nOne of its features includes [`Consumer Groups`](https://redis.io/topics/streams-intro#consumer-groups), that allows a group of clients to co-operate consuming a different portion of the same stream of messages.\n\nThis specification describes the `redis-streams` trigger that scales based on the *Pending Entries List* (see [`XPENDING`](https://redis.io/commands/xpending)) for a specific Consumer Group of a Redis Stream.\n\n\n```yaml\ntriggers:\n- type: redis-streams\n  metadata:\n    address: localhost:6379 # Required if host and port are not provided. Format - host:port\n    host: localhost # Required if address is not provided\n    port: \"6379\" # Required if address is not provided and host has been provided.\n    usernameFromEnv: REDIS_USERNAME # optional (can also use authenticationRef)\n    passwordFromEnv: REDIS_PASSWORD # optional (can also use authenticationRef)\n    stream: my-stream # Required - name of the Redis Stream\n    consumerGroup: my-consumer-group # Required - name of consumer group associated with Redis Stream\n    pendingEntriesCount: \"10\" # Required - number of entries in the Pending Entries List for the specified consumer group in the Redis Stream\n    enableTLS: \"false\" # optional\n    databaseIndex: \"0\" # optional\n    # Alternatively, you can use existing environment variables to read configuration from:\n    # See details in \"Parameter list\" section\n    addressFromEnv: REDIS_ADDRESS # Optional. You can use this instead of `address` parameter\n    hostFromEnv: REDIS_HOST # Optional. You can use this instead of `host` parameter\n    portFromEnv: REDIS_PORT # Optional. You can use this instead of `port` parameter\n```\n\n**Parameter list:**\n\n- `address` -  The host and port of the Redis server in the format `host:port`, for example `my-redis:6379`.\n\n> As an alternative to the `address` field, the user can specify `host` and `port` parameters.\n\n- `host` - The host of the Redis server.\n\n> It is not required if `address` has been provided.\n\n- `port` - The port of the Redis server.\n\n> It is only to be used along with the `host`/`hostFromEnv` attribute and not required if `address` has been provided.\n\n- `usernameFromEnv` - Name of the environment variable your deployment uses to get the Redis username. (Optional)\n- `passwordFromEnv` - Name of the environment variable your deployment uses to get the Redis password. (Optional)\n\n- `stream` - Name of the Redis Stream.\n- `consumerGroup` - Name of the Consumer group associated with Redis Stream.\n- `pendingEntriesCount` - Threshold for the number of `Pending Entries List`. This is the average target value to scale the workload. (Default: `5`, Optional)\n- `databaseIndex` - The Redis database index. Defaults to `0` if not specified.\n- `enableTLS` - Allow a connection to Redis using tls. (Values: `true`, `false`, Default: `false`, Optional)\n\nSome parameters could be provided using environmental variables, instead of setting them directly in metadata. Here is a list of parameters you can use to retrieve values from environment variables:\n\n- `addressFromEnv` - The host and port of the Redis server, similar to `address`, but reads it from an environment variable on the scale target. Name of the environment variable your deployment uses to get the Redis server URL. The resolved host should follow a format like `my-redis:6379`.\n- `hostFromEnv` - The host of the Redis server, similar to `host`, but reads it from an environment variable on the scale target.\n- `portFromEnv` - The port of the Redis server, similar to `port`, but reads it from an environment variable on the scale target.\n\n### Authentication Parameters\n\nThe scaler supports two modes of authentication:\n\n#### Using username/password authentication\n\nUse the `username` and `password` field in the `metadata` to specify the name of an environment variable that your deployment uses to get the Redis username/password.\n\nThis is usually resolved from a `Secret V1` or a `ConfigMap V1` collections. `env` and `envFrom` are both supported.\n\nHere is an example:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        addressFromEnv: REDIS_HOST\n        usernameFromEnv: REDIS_USERNAME # name of the environment variable in the Deployment\n        passwordFromEnv: REDIS_PASSWORD # name of the environment variable in the Deployment\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n```\n\n#### Using `TriggerAuthentication`\n\nYou can use `TriggerAuthentication` CRD to configure the authentication. For example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: redis-streams-auth\ntype: Opaque\ndata:\n  redis_username: <encoded redis username>\n  redis_password: <encoded redis password>\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-redis-stream-triggerauth\nspec:\n  secretTargetRef:\n    - parameter: username\n      name: redis-streams-auth # name of the Secret\n      key: redis_username # name of the key in the Secret\n    - parameter: password\n      name: redis-streams-auth # name of the Secret\n      key: redis_password # name of the key in the Secret\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: redis-streams-scaledobject\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: redis-streams-consumer\n  pollingInterval: 15\n  cooldownPeriod: 200\n  maxReplicaCount: 25\n  minReplicaCount: 1\n  triggers:\n    - type: redis-streams\n      metadata:\n        address: localhost:6379\n        stream: my-stream\n        consumerGroup: consumer-group-1\n        pendingEntriesCount: \"10\"\n      authenticationRef:\n        name: keda-redis-stream-triggerauth # name of the TriggerAuthentication resource\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/selenium-grid-scaler.md",
    "content": "+++\ntitle = \"Selenium Grid Scaler\"\navailability = \"v2.4+\"\nmaintainer = \"Volvo Cars\"\ndescription = \"Scales Selenium browser nodes based on number of requests waiting in session queue\"\ngo_file = \"selenium_grid_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `selenium-grid` trigger that scales browser nodes based on number of requests in session queue and the max sessions per grid.\n\nThe scaler creates one browser node per pending request in session queue, divided by the max amount of sessions that can run in parallel. You will have to create one trigger per browser capability that you would like to support in your Selenium Grid.\n\nThe below is an example trigger configuration for chrome node.\n\n```yaml\ntriggers:\n  - type: selenium-grid\n    metadata:\n      url: 'http://selenium-hub:4444/graphql' # Required. Can be ommitted if specified via TriggerAuthentication/ClusterTriggerAuthentication.\n      browserName: 'chrome'  # Required\n      browserVersion: '91.0' # Optional. Only required when supporting multiple versions of browser in your Selenium Grid.\n      unsafeSsl : 'true' # Optional\n      activationThreshold: 5 # Optional\n```\n\n**Parameter list:**\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) to for more info.\n- `browserName` - Name of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info.\n- `sessionBrowserName` -  Name of the browser when it is an active session, only set if `BrowserName` changes between the queue and the active session. See the Edge example below for further detail. (Optional)\n- `browserVersion` - Version of browser that usually gets passed in the browser capability. Refer to the [Selenium Grid's](https://www.selenium.dev/documentation/en/getting_started_with_webdriver/browsers/) and [WebdriverIO's](https://webdriver.io/docs/options/#capabilities) documentation for more info. (Optional)\n- `unsafeSsl` - Skip certificate validation when connecting over HTTPS. (Values: `true`, `false`, Default: `false`, Optional)\n- `activationThreshold` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n\n### Example\n\nHere is a full example of scaled object definition using Selenium Grid trigger:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n```\n\nThe above example will create Chrome browser nodes equal to the requests pending in session queue for Chrome browser.\n\nSimilarly for Firefox\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-firefox-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-firefox-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-firefox-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'firefox'\n```\n\nSimilarly for Edge. Note that for Edge you must set the `sessionBrowserName` to `msedge` inorder for scaling to work properly.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-edge-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-edge-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-edge-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'MicrosoftEdge'\n        sessionBrowserName: 'msedge'\n```\n\nIf you are supporting multiple versions of browser capability in your Selenium Grid, You should create one scaler for every browser version and pass the `browserVersion` in the metadata.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-91-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-91\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-91\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '91.0'\n```\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-90-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node-90\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node-90\n  triggers:\n    - type: selenium-grid\n      metadata:\n        url: 'http://selenium-hub:4444/graphql'\n        browserName: 'chrome'\n        browserVersion: '90.0'\n```\n\n### Authentication Parameters\n\nIt is possible to specify the Graphql url of your Selenium Grid using authentication parameters. This useful if you have enabled Selenium Grid's Basic HTTP Authentication and would like to keep your credentials secure.\n\n- `url` - Graphql url of your Selenium Grid. Refer to the Selenium Grid's documentation [here](https://www.selenium.dev/documentation/en/grid/grid_4/graphql_support/) for more info.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: selenium-grid-secret\n  namespace: keda\ntype: Opaque\ndata:\n  graphql-url: base64 encoded value of GraphQL URL\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: keda-trigger-auth-selenium-grid-secret\n  namespace: keda\nspec:\n  secretTargetRef:\n  - parameter: url\n    name: selenium-grid-secret\n    key: graphql-url\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: selenium-grid-chrome-scaledobject\n  namespace: keda\n  labels:\n    deploymentName: selenium-chrome-node\nspec:\n  maxReplicaCount: 8\n  scaleTargetRef:\n    name: selenium-chrome-node\n  triggers:\n    - type: selenium-grid\n      metadata:\n        browserName: 'chrome'\n      authenticationRef:\n        name: keda-trigger-auth-selenium-grid-secret\n```\n"
  },
  {
    "path": "content/docs/2.9/scalers/solace-pub-sub.md",
    "content": "+++\ntitle = \"Solace PubSub+ Event Broker\"\navailability = \"2.4+\"\nmaintainer = \"Community\"\ndescription = \"Scale applications based on Solace PubSub+ Event Broker Queues\"\ngo_file = \"solace_scaler\"\n+++\n\n### Trigger Specification\n\nThis specification describes the `solace-event-queue` trigger that scales based on a Solace PubSub+ Event Broker queue.\n\n```yaml\ntriggers:\n- type: solace-event-queue\n  metadata:\n    solaceSempBaseURL:                  http://solace_broker:8080\n    messageVpn:                         message-vpn\n    queueName:                          queue_name\n    messageCountTarget:                 '100'\n    messageSpoolUsageTarget:            '100'       ### Megabytes (MB)\n    activationMessageCountTarget:       '100'\n    activationMessageSpoolUsageTarget:  '100'       ### Megabytes (MB)\n    username:                           semp-user\n    password:                           semp-pwd\n    usernameFromEnv:                    ENV_VAR_USER\n    passwordFromEnv:                    ENV_VAR_PWD\n```\n\n**Parameter list:**\n\n- `solaceSempBaseURL` - Solace SEMP Endpoint in format: `<protocol>://<host-or-service>:<port>`.\n- `messageVpn` - Message VPN hosted on the Solace broker.\n- `queueName` - Message Queue to be monitored.\n- `messageCountTarget` - The target number of messages manageable by a pod. The scaler will cause the replicas to increase if the queue message backlog is greater than the target value per active replica.\n- `activationMessageCountTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `messageSpoolUsageTarget` - Integer value expressed in Megabytes (MB). The target spool usage manageable by a pod. The scaler will cause the replicas to increase if the queue spool usage is greater than the target value per active replica.\n- `activationMessageSpoolUsageTarget` - Target value for activating the scaler. Learn more about activation [here](./../concepts/scaling-deployments.md#activating-and-scaling-thresholds). (Default: `0`, Optional)\n- `username` - User account with access to Solace SEMP RESTful endpoint.\n- `password` - Password for the user account.\n- `usernameFromEnv` - Environment variable set with SEMP user account.\n- `passwordFromEnv` - Environment variable set with password for the user account.\n\n**Parameter Requirements:**\n\n- Parameters resolving the target queue are all **required:** `solaceSempBaseURL`, `messageVpn`, `queueName`\n- **At least** one of `messageCountTarget` or `messageSpoolUsageTarget` is **required.** If both values are present, the metric value resulting in the higher desired replicas will be used. (Standard KEDA/HPA behavior)\n- The Solace PubSub+ Scaler polls the Solace SEMP REST API to monitor target queues. Currently, the scaler supports basic authentication. `username` and `password` are **required** for the `solace-event-queue` trigger to function. These values may be set directly in the trigger metadata or using a TriggerAuthentication record. See [Authentication Parameters](#authentication-parameters) below. Alternatively, credentials may be passed from environment variables identified by `usernameFromEnv` and `passwordFromEnv`.\n\n### Authentication Parameters\n\nYou can use TriggerAuthentication CRD to configure the username and password to connect to the management endpoint.\n\n**Username and Password based authentication:**\n- `username` - Required. The username to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n- `password` - Required. The password to use to connect to the Solace PubSub+ Event Broker's SEMP endpoint.\n\n### Example\n\nThe objects in the example below are declared in `namespace=solace`. It is not required to do so. If you do define a namespace for the configuration objects, then they should all be declared in the same namespace.\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name:      solace-secret\n  namespace: solace\n  labels:\n    app: solace-consumer\ntype: Opaque\ndata:\n  SEMP_USER:         YWRtaW4=\n  SEMP_PASSWORD:     S2VkYUxhYkFkbWluUHdkMQ==\n---\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name:      solace-scaled-object\n  namespace: solace\nspec:\n  scaleTargetRef:\n    apiVersion:    apps/v1\n    kind:          Deployment\n    name:          solace-consumer\n  pollingInterval: 20\n  cooldownPeriod:  60\n  minReplicaCount:  0\n  maxReplicaCount: 10\n  triggers:\n  - type: solace-event-queue\n    metadata:\n      solaceSempBaseURL:       http://broker-pubsubplus.solace.svc.cluster.local:8080\n      messageVpn:              test_vpn\n      queueName:               SCALED_CONSUMER_QUEUE1\n      messageCountTarget:      '50'\n      messageSpoolUsageTarget: '100000'\n    authenticationRef:\n      name: solace-trigger-auth\n---\napiVersion: keda.sh/v1alpha1\nkind: TriggerAuthentication\nmetadata:\n  name: solace-trigger-auth\n  namespace: solace\nspec:\n  secretTargetRef:\n    - parameter:   username\n      name:        solace-secret\n      key:         SEMP_USER\n    - parameter:   password\n      name:        solace-secret\n      key:         SEMP_PASSWORD\n```\n"
  },
  {
    "path": "content/docs/2.9/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"How to address commonly encountered KEDA issues\"\n+++\n\n{{< troubleshooting >}}\n"
  },
  {
    "path": "content/docs/_index.md",
    "content": "---\nbuild:\n  render: false\n---\n"
  },
  {
    "path": "content/enterprise.md",
    "content": "+++\ntitle = \"Enterprise\"\ndescription = \"Enterprise and commercially supported solutions based on KEDA\"\n+++\n\n{{< enterprise >}}\n"
  },
  {
    "path": "content/http-add-on/0.14/_index.md",
    "content": "+++\ntitle = \"KEDA HTTP Add-on\"\ndescription = \"HTTP-based autoscaling for Kubernetes workloads, including scale-to-zero\"\nweight = 1\n+++\n\nThe KEDA HTTP Add-on enables automatic scaling of HTTP workloads on Kubernetes based on incoming traffic, including scaling to and from zero replicas.\nIt extends [KEDA](https://keda.sh) with the infrastructure needed to intercept HTTP requests, count them, and report metrics that drive scaling decisions.\n\n## How It Works\n\nThe HTTP Add-on deploys three components into your cluster:\n\n- An **interceptor** that sits in front of your application as a reverse proxy, routing requests and tracking concurrency.\n- A **scaler** that aggregates request metrics from the interceptor and reports them to KEDA.\n- An **operator** that manages the lifecycle of scaling resources.\n\nYou create an `InterceptorRoute` to define how traffic reaches your service and a KEDA `ScaledObject` to control scaling behavior.\nThe interceptor handles requests while KEDA scales your workload up and down based on demand.\n\n## Get Started\n\nIf you are new to the HTTP Add-on, follow the [Getting Started guide](getting-started/) to deploy and scale your first HTTP application.\n\n## Upgrading from a Previous Version\n\nv0.14.0 introduces the `InterceptorRoute` (v1beta1) API, which replaces `HTTPScaledObject` (v1alpha1).\nIf you have existing `HTTPScaledObject` resources, see [Migrate from HTTPScaledObject to InterceptorRoute](operations/migrate-httpscaledobject-to-interceptorroute/).\n\n## Documentation Sections\n\n- **[Getting Started](getting-started/)** — Tutorial: install the add-on and scale your first app end-to-end.\n- **[Concepts](concepts/)** — Understand the architecture, scaling mechanics, and routing model.\n- **[User Guide](user-guide/)** — Configure autoscaling, routing, and timeouts for your HTTP applications.\n- **[Operations](operations/)** — Install, configure, and manage the HTTP Add-on infrastructure.\n- **[Reference](reference/)** — API specifications, Helm chart values, environment variables, and metrics.\n\n## Getting Help\n\n- [Kubernetes Slack](https://kubernetes.slack.com/archives/CKZJ36A5D) — `#keda` channel ([join here](https://slack.k8s.io))\n- [GitHub Issues](https://github.com/kedacore/http-add-on/issues) — Bug reports and feature requests\n- [GitHub Discussions](https://github.com/kedacore/http-add-on/discussions) — Questions and general conversation\n\n## Contributing\n\nContributions to the HTTP Add-on are welcome.\nSee the [contributing guide](https://github.com/kedacore/http-add-on/blob/main/CONTRIBUTING.md) in the source repository for development setup, commit conventions, and PR guidelines.\n"
  },
  {
    "path": "content/http-add-on/0.14/concepts/_index.md",
    "content": "+++\ntitle = \"Concepts\"\ndescription = \"Architecture, scaling mechanics, and routing model of the HTTP Add-on\"\nweight = 200\n+++\n\nLearn how the HTTP Add-on works before configuring it.\n\n- **[Architecture](architecture/)** — The three components, how they interact, and the request flow.\n- **[Routing](routing/)** — Host, path, and header matching with priority rules.\n- **[Scaling](scaling/)** — Scaling metrics, scale-to-zero, and cold-start behavior.\n"
  },
  {
    "path": "content/http-add-on/0.14/concepts/architecture.md",
    "content": "+++\ntitle = \"Architecture\"\ndescription = \"The three components of the HTTP Add-on, their responsibilities, and how they interact to scale HTTP workloads\"\n+++\n\n## The Problem: HTTP Has No Queue\n\nEvent-driven scalers such as those for Kafka or RabbitMQ can read the number of pending messages directly from a broker.\nHTTP has no equivalent concept: a request arrives, gets processed, and is gone.\nThere is nothing for an autoscaler to query.\n\nThe HTTP Add-on solves this by placing dedicated infrastructure in the request path.\nAn interceptor proxy sits in front of your application, counts requests as they flow through, and holds requests during cold starts while backends scale up.\nA scaler component aggregates those counts into metrics that [KEDA](https://keda.sh/docs/) can use to drive the Horizontal Pod Autoscaler (HPA).\n\n## KEDA Core Concepts\n\nBefore diving into the HTTP Add-on components, a few KEDA primitives are relevant:\n\n- **ScaledObject** — A KEDA custom resource that binds a workload (Deployment, StatefulSet, etc.) to one or more scaling triggers. KEDA watches ScaledObjects and configures the Kubernetes HPA accordingly. See the [KEDA ScaledObject documentation](https://keda.sh/docs/latest/concepts/scaling-deployments/).\n- **External scaler** — A gRPC service that KEDA calls to fetch custom metrics. The HTTP Add-on's scaler component implements this interface. See the [KEDA external scalers documentation](https://keda.sh/docs/latest/concepts/external-scalers/).\n- **HPA** — The Kubernetes Horizontal Pod Autoscaler. KEDA creates and manages an HPA for each ScaledObject. The HPA adjusts replica counts based on the metrics KEDA feeds it.\n\n## Component Overview\n\nThe HTTP Add-on consists of three components deployed into the cluster:\n\n### Interceptor\n\nThe interceptor is a reverse proxy that sits in the request path between the ingress layer and the backend service.\nIt performs three functions:\n\n1. **Routing** — Matches incoming requests to backend services based on hostname, path prefix, and headers. See [Routing](../routing/) for the matching model.\n2. **Counting** — Tracks the number of concurrent (in-flight) requests and total request counts per route. These counters are the raw data the scaler uses to compute scaling metrics.\n3. **Buffering** — During cold starts (when a backend has zero replicas), the interceptor holds the request open while waiting for the backend to become ready. Once at least one pod is available, the request is forwarded. If the backend does not become ready within the readiness timeout, the interceptor returns an error or routes to a fallback service if configured.\n\nThe interceptor forwards requests to the backend's Kubernetes Service, relying on standard Kubernetes service load balancing for distribution across pods.\n\nThe interceptor deployment is itself auto-scaled by KEDA via a ScaledObject created by the Helm chart.\n\n### Scaler\n\nThe scaler is the bridge between the interceptor's in-memory counters and KEDA's scaling decisions.\nIt implements the KEDA external scaler interface.\n\nThe scaler periodically polls all interceptor pods to fetch per-route request counts.\nIt aggregates concurrency across pods for each route and computes request rate from the total request counters.\nWhen KEDA queries the scaler, it returns these aggregated metrics so KEDA can adjust replica counts.\n\nSee [Scaling](../scaling/) for details on how these metrics drive scaling decisions.\n\n### Operator\n\nThe operator is a Kubernetes controller manager that reconciles HTTP Add-on custom resources:\n\n- **InterceptorRoute** (`http.keda.sh/v1beta1`) — Defines routing rules, scaling metrics, target service, and timeout/cold-start configuration in a single resource. Users pair it with a KEDA ScaledObject they create and manage.\n- **HTTPScaledObject** (`http.keda.sh/v1alpha1`, deprecated) — Combines routing, scaling, and ScaledObject management in one resource. The operator automatically creates the corresponding ScaledObject.\n\nSee the [InterceptorRoute reference](../../reference/interceptorroute/) for the full API specification.\n\n## Request Flow\n\n```\n+---------+     +-------------+     +---------+\n| Ingress +---->| Interceptor +---->| Backend |\n+---------+     +------+------+     +---------+\n                       |\n                  poll metrics\n                       |\n                +------+------+\n                |   Scaler    |\n                +------+------+\n                       |\n                  report metrics\n                       |\n                +------+------+\n                |  KEDA Core  |\n                +------+------+\n                       |\n                  adjust replicas\n                       |\n                +------+------+\n                |     HPA     |\n                +-------------+\n```\n\n1. External traffic enters the cluster through an ingress controller (or Gateway API) and is routed to the interceptor service.\n2. The interceptor matches the request to a route, counts it, and forwards the request to the backend. If the backend has zero replicas, the interceptor holds the request until a pod becomes ready.\n3. When the backend responds, the interceptor returns the response to the client.\n4. The scaler polls the interceptor to aggregate request counts and compute rate metrics.\n5. KEDA queries the scaler for current metrics and determines the desired replica count.\n6. KEDA configures the HPA, which adjusts the backend's replica count.\n\n## What's Next\n\n- [Scaling](../scaling/) — How scaling decisions are made, including scale-to-zero and cold starts.\n- [Routing](../routing/) — How requests are matched to InterceptorRoutes.\n- [Install the HTTP Add-on](../../operations/installation/) — Install the HTTP Add-on via Helm.\n"
  },
  {
    "path": "content/http-add-on/0.14/concepts/routing.md",
    "content": "+++\ntitle = \"Routing\"\ndescription = \"Interceptor request matching using hostname, path, and header rules\"\n+++\n\nThe interceptor maintains an in-memory routing table that maps incoming HTTP requests to InterceptorRoute resources.\nEach InterceptorRoute defines one or more routing rules, and each rule can match on three dimensions: hostname, path prefix, and headers.\n\n## Routing Rules\n\nAn InterceptorRoute contains a list of routing rules in `spec.rules`.\nEach rule specifies hosts, paths, and headers to match.\nA request that matches any rule in the InterceptorRoute is forwarded to that InterceptorRoute's target service.\n\nWhen a rule omits hosts, it matches any hostname (catch-all).\nWhen it omits paths, it matches the root path `/`.\nWhen it omits headers, no header matching is performed.\n\n## Matching Dimensions\n\n### Hostname Matching\n\nThe interceptor matches the `Host` header of the request against the hostnames declared in routing rules.\nThree kinds of hostname values are supported:\n\n- **Exact hostnames** (`api.example.com`)\n  - Match the request hostname exactly.\n  - Exact matches take priority over all wildcard forms.\n- **Wildcard hostnames** (`*.example.com`)\n  - The `*` replaces the first DNS label.\n  - A wildcard matches any hostname that ends with the remaining labels: `*.example.com` matches `foo.example.com` and `foo.bar.example.com` (multi-level).\n  - More specific wildcards take priority: `*.bar.example.com` wins over `*.example.com` for a request to `api.bar.example.com`.\n- **Catch-all** (`*` or omitted)\n  - Matches any hostname.\n  - This is the lowest priority.\n\nThe interceptor evaluates hostnames in priority order: exact match first, then wildcards from most specific to least specific, then catch-all.\n\n### Path Matching\n\nThe interceptor uses longest-prefix matching on the request path.\nAll paths are normalized by trimming leading and trailing slashes.\n\nWhen multiple routes match on hostname, the route with the longest matching path prefix wins.\nFor example, a request to `/api/v1/users` matches a rule with path `/api/v1` over a rule with path `/api`.\n\nThe routing table uses a radix tree internally, which makes longest-prefix lookups efficient regardless of the number of routes.\n\n### Header Matching\n\nHeader matching adds a further dimension of specificity.\nA routing rule can declare one or more headers that the request must carry:\n\n- **Exact value match** — The rule specifies both a header name and a value (e.g., `name: X-Route, value: canary`). The request must contain the header with that exact value.\n- **Presence-only match** — The rule specifies a header name without a value (e.g., `name: X-Route`). The request must contain the header, but any value is accepted.\n\nAll headers in a single rule must match for the rule to apply (AND semantics).\nIf a rule declares no headers, it matches regardless of what headers the request carries.\n\n## Priority Order\n\nWhen multiple InterceptorRoutes match a request, the interceptor selects the most specific one using the following tiebreaking order:\n\n1. **Most specific hostname** — Exact hostname wins over wildcard, which wins over catch-all. Among wildcards, more specific patterns (more labels) take priority.\n2. **Longest path prefix** — A longer matching prefix wins.\n3. **Most specific headers** — Routes with more header matchers take priority. Among routes with the same number of headers, routes with more exact-value matches (as opposed to presence-only matches) take priority.\n4. **Oldest creation timestamp** — The InterceptorRoute created first wins.\n5. **Lexicographic namespace/name** — Final tiebreaker using the resource's namespace and name in descending lexicographic order.\n\n### Example\n\nConsider three InterceptorRoutes:\n\n| Route | Host              | Path      | Headers        |\n| ----- | ----------------- | --------- | -------------- |\n| A     | `api.example.com` | `/api`    | (none)         |\n| B     | `*.example.com`   | `/api/v1` | `X-Version: 2` |\n| C     | `api.example.com` | `/api/v1` | (none)         |\n\nA request to `api.example.com` with path `/api/v1/users` and header `X-Version: 2`:\n\n- Route A matches (exact host, path `/api` is a prefix).\n- Route B matches (wildcard host, path `/api/v1` is a prefix, header matches).\n- Route C matches (exact host, path `/api/v1` is a prefix).\n\nApplying the priority rules: Routes A and C have an exact hostname, which beats B's wildcard.\nBetween A and C, C has the longer path prefix (`/api/v1` vs `/api`).\n**Route C wins.**\n\n## Multiple Rules per InterceptorRoute\n\nA single InterceptorRoute can contain multiple routing rules.\nEach rule independently specifies its own hosts, paths, and headers.\nA request that matches any one of these rules is routed to the InterceptorRoute's target service.\n\nThis allows a single InterceptorRoute to serve traffic for multiple hostnames or path patterns without requiring separate resources for each.\n\n## What's Next\n\n- [Configure Routing Rules](../../user-guide/configure-routing/) — YAML examples for host, path, and header matching.\n- [InterceptorRoute Reference](../../reference/interceptorroute/) — Complete field definitions for routing rules.\n"
  },
  {
    "path": "content/http-add-on/0.14/concepts/scaling.md",
    "content": "+++\ntitle = \"Scaling\"\ndescription = \"HTTP Add-on scaling decisions, including metrics, scale-to-zero, and cold-start behavior\"\n+++\n\nThe HTTP Add-on provides two scaling metrics: concurrency and request rate.\nKEDA uses these metrics to adjust the replica count of backend workloads through the Horizontal Pod Autoscaler (HPA).\n\n## Scaling Metrics\n\n### Concurrency\n\nConcurrency measures the number of in-flight requests at any instant for a given route.\nThe interceptor increments a counter when a request arrives and decrements it when the response completes.\n\n### Request Rate\n\nRequest rate measures the number of requests per second, averaged over a sliding time window.\nThe windowed averaging smooths out short bursts and provides a stable signal for scaling.\n\nThe default configuration is:\n\n- **Window**: 1 minute\n- **Granularity**: 1 second\n\n### Using Both Metrics\n\nWhen an InterceptorRoute specifies both concurrency and request rate targets, KEDA evaluates each metric independently and scales to whichever demands more replicas.\nThis is standard KEDA/HPA behavior: the metric requiring the highest replica count wins.\n\n## The Scaling Formula\n\nThe desired replica count for a single metric follows the standard HPA formula:\n\n```\ndesiredReplicas = ceil(currentMetricValue / targetValue)\n```\n\nFor example, with a concurrency target of 100 and a current concurrency of 250, the desired count is `ceil(250 / 100) = 3`.\n\nThis calculation happens within the Kubernetes HPA based on the metrics and targets that KEDA provides.\n\n## How Metrics Flow\n\n1. A request arrives at the interceptor, which counts it.\n2. The scaler periodically polls all interceptor pods to collect per-route request counts.\n3. The scaler aggregates concurrency across pods and computes request rate for each route.\n4. KEDA queries the scaler for current metrics and determines the desired replica count.\n5. KEDA configures the HPA, which adjusts the backend's replica count.\n\n## Scale-to-Zero\n\nWhen all metrics for a route drop to zero and the ScaledObject's `cooldownPeriod` expires, KEDA scales the backend workload to zero replicas.\n\nThe `cooldownPeriod` is a field on the KEDA ScaledObject (not the InterceptorRoute).\nIt defines how long all metrics must remain at zero before KEDA scales the workload down to zero.\n\n## Cold Starts\n\nWhen a request arrives for a backend that has been scaled to zero, the interceptor holds the request while KEDA scales the backend up.\nThe sequence is:\n\n1. The interceptor matches the request to a route and counts it.\n2. The scaler detects incoming traffic and reports the workload as active to KEDA.\n3. KEDA scales the backend workload from 0 to 1 or more replicas.\n4. Once at least one backend pod is ready, the interceptor forwards the held request.\n5. The response flows back through the interceptor to the client.\n\nIf the backend does not become ready within the readiness timeout, the interceptor either routes to a fallback service (if configured) or returns an error.\nSee [Configure Cold-Start Behavior](../../user-guide/configure-cold-start/) for fallback configuration and [Configure Timeouts](../../user-guide/configure-timeouts/) for timeout settings.\n\n## What's Next\n\n- [Configure Scaling Metrics](../../user-guide/configure-scaling/) — Choose between concurrency and request rate, and tune target values.\n- [Configure Timeouts](../../user-guide/configure-timeouts/) — Set readiness timeouts per route.\n- [Configure Cold-Start Behavior](../../user-guide/configure-cold-start/) — Fallback services and cold-start response headers.\n- [Architecture](../architecture/) — Overview of the three components and how they interact.\n"
  },
  {
    "path": "content/http-add-on/0.14/getting-started/_index.md",
    "content": "+++\ntitle = \"Getting Started\"\ndescription = \"Sample HTTP application deployment and autoscaling with the KEDA HTTP Add-on\"\nweight = 100\n+++\n\nIn this tutorial, we will install the KEDA HTTP Add-on and use it to autoscale an HTTP application based on incoming traffic — including scaling to zero when idle.\n\nBy the end, we will have:\n\n- A sample HTTP application running in our cluster\n- The HTTP Add-on intercepting and counting requests\n- KEDA scaling the application up under load and back to zero when traffic stops\n\n## Prerequisites\n\nBefore we begin, we need:\n\n- A Kubernetes cluster (kind, minikube, or a cloud provider)\n- `kubectl` configured to access the cluster\n- [Helm 3](https://helm.sh/docs/intro/install/) installed\n- KEDA core installed:\n\n  ```shell\n  helm install keda kedacore/keda --namespace keda --create-namespace\n  ```\n\n  See the [KEDA deployment docs](https://keda.sh/docs/deploy/) for other installation methods.\n\n## Step 1: Add the KEDA Helm Repository\n\nIf we have not already added the KEDA Helm repository, we add it now and update our local chart index:\n\n```shell\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\n```\n\n## Step 2: Install the HTTP Add-on\n\nWe install the HTTP Add-on into the same `keda` namespace where KEDA core is running:\n\n```shell\nhelm install http-add-on kedacore/keda-add-ons-http --namespace keda\n```\n\nWe verify that all components are running:\n\n```shell\nkubectl get pods -n keda\n```\n\nWe will see pods for the operator, interceptor, and scaler — all with a `Running` status:\n\n```\nNAME                                                   READY   STATUS    RESTARTS   AGE\nkeda-add-ons-http-interceptor-...                      1/1     Running   0          30s\nkeda-add-ons-http-operator-...                         1/1     Running   0          30s\nkeda-add-ons-http-scaler-...                           1/1     Running   0          30s\nkeda-admission-webhooks-...                            1/1     Running   0          2m\nkeda-operator-...                                      1/1     Running   0          2m\nkeda-operator-metrics-apiserver-...                    1/1     Running   0          2m\n```\n\n## Step 3: Deploy a Sample Application\n\nWe create a namespace and deploy a sample HTTP application using [traefik/whoami](https://github.com/traefik/whoami), a lightweight HTTP server that responds with request metadata.\n\n```shell\nkubectl create namespace demo\n```\n\nWe deploy a Deployment and Service:\n\n```shell\nkubectl apply -f - <<EOF\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: sample-app\n  namespace: demo\nspec:\n  selector:\n    matchLabels:\n      app: sample-app\n  template:\n    metadata:\n      labels:\n        app: sample-app\n    spec:\n      containers:\n        - name: sample-app\n          image: traefik/whoami\n          args: [\"--port=8080\"]\n          ports:\n            - containerPort: 8080\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: sample-app\n  namespace: demo\nspec:\n  selector:\n    app: sample-app\n  ports:\n    - port: 80\n      targetPort: 8080\nEOF\n```\n\nWe verify the Deployment was created:\n\n```shell\nkubectl get deployment -n demo\n```\n\nWe will see the Deployment with 1 replica running (the Kubernetes default):\n\n```\nNAME         READY   UP-TO-DATE   AVAILABLE   AGE\nsample-app   1/1     1            1           10s\n```\n\n## Step 4: Create an InterceptorRoute\n\nThe `InterceptorRoute` tells the interceptor how to route requests to our sample app and what scaling metric to use.\n\n```shell\nkubectl apply -f - <<EOF\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: sample-app\n  namespace: demo\nspec:\n  target:\n    service: sample-app\n    port: 80\n  rules:\n    - hosts:\n        - sample-app.example.com\n  scalingMetric:\n    requestRate:\n      targetValue: 5\n      window: 1m\n      granularity: 1s\nEOF\n```\n\nThe `requestRate` metric scales based on requests per second, averaged over the configured `window`.\nA `targetValue: 5` means the add-on targets 5 requests per second per replica.\nWe use a low value here so that scaling is visible during testing.\nSee [Scaling](../concepts/scaling/) for details on scaling metrics and how to tune them.\n\nWe verify the InterceptorRoute is ready:\n\n```shell\nkubectl get interceptorroute -n demo\n```\n\nWe will see:\n\n```\nNAME         TARGETSERVICE   READY   AGE\nsample-app   sample-app      True    10s\n```\n\n## Step 5: Create a ScaledObject\n\nThe `ScaledObject` tells KEDA how to scale our `sample-app` deployment.\nIt uses the `external-push` trigger type, which receives metrics from the HTTP Add-on's scaler component.\n\n```shell\nkubectl apply -f - <<EOF\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: sample-app\n  namespace: demo\nspec:\n  scaleTargetRef:\n    name: sample-app\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  cooldownPeriod: 30\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: keda-add-ons-http-external-scaler.keda:9090\n        interceptorRoute: sample-app\nEOF\n```\n\nThe `interceptorRoute` value must match the name of the `InterceptorRoute` we created in the previous step.\nSee [Architecture](../concepts/architecture/) for details on how these components connect.\n\nWe verify the ScaledObject was created:\n\n```shell\nkubectl get scaledobject -n demo\n```\n\nWe will see:\n\n```\nNAME         SCALETARGETKIND      SCALETARGETNAME   MIN   MAX   TRIGGERS        ...\nsample-app   apps/v1.Deployment   sample-app        0     10    external-push   ...\n```\n\n## Step 6: Send Traffic and Observe Scaling\n\nNow we test that autoscaling works.\nSince there is no traffic, KEDA has scaled the deployment to 0 replicas.\nWe verify this:\n\n```shell\nkubectl get deployment sample-app -n demo\n```\n\n```\nNAME         READY   UP-TO-DATE   AVAILABLE   AGE\nsample-app   0/0     0            0           2m\n```\n\nFor testing, we use `kubectl port-forward` to access the interceptor proxy.\nIn production, your ingress or gateway must route traffic to the interceptor proxy service (`keda-add-ons-http-interceptor-proxy`) instead of directly to your application — see [Configure Ingress](../user-guide/configure-ingress/) for details.\n\n```shell\nkubectl port-forward -n keda svc/keda-add-ons-http-interceptor-proxy 8090:8080\n```\n\nIn another terminal, we send a request with the matching `Host` header:\n\n```shell\ncurl -H \"Host: sample-app.example.com\" localhost:8090\n```\n\nThe first request may take a few seconds.\nThis is the cold start: KEDA is scaling the deployment from 0 to 1 replica, and the interceptor holds the request until the pod is ready.\nWe will see a response from the sample app once the pod starts.\n\nWe check replicas again:\n\n```shell\nkubectl get deployment sample-app -n demo\n```\n\nWe will see 1 replica running:\n\n```\nNAME         READY   UP-TO-DATE   AVAILABLE   AGE\nsample-app   1/1     1            1           3m\n```\n\n## Step 7: Generate Load and Watch It Scale Up\n\nTo see scaling beyond 1 replica, we generate a burst of traffic.\nThe `wait=50ms` query parameter tells whoami to hold each response for 50 milliseconds, which produces a steady rate of about 20 requests per second — enough to trigger scaling with our `targetValue` of 5:\n\n```shell\nfor i in $(seq 1 300); do curl -s -H \"Host: sample-app.example.com\" \"localhost:8090/?wait=50ms\" > /dev/null; done\n```\n\nAfter the burst finishes, we check the deployment:\n\n```shell\nkubectl get deployment sample-app -n demo\n```\n\nWe will see the replica count has increased:\n\n```\nNAME         READY   UP-TO-DATE   AVAILABLE   AGE\nsample-app   2/2     2            2           5m\n```\n\n## Step 8: Observe Scale to Zero\n\nAfter the burst ends and the cooldown period passes (30 seconds, as configured in our ScaledObject), KEDA scales the deployment back to 0.\nWe can watch this happen:\n\n```shell\nkubectl get deployment sample-app -n demo -w\n```\n\nWe will see replicas decrease to 0:\n\n```\nNAME         READY   UP-TO-DATE   AVAILABLE   AGE\nsample-app   2/2     2            2           5m\nsample-app   1/1     1            1           6m\nsample-app   0/0     0            0           7m\n```\n\n## Step 9: Clean Up\n\nTo remove the sample application and all its resources:\n\n```shell\nkubectl delete namespace demo\n```\n\n## What's Next\n\n- [Architecture](../concepts/architecture/) — Understand how the interceptor, scaler, and operator work together.\n- [Autoscale an App](../user-guide/autoscale-an-app/) — Apply this pattern to your own services.\n- [Configure Ingress](../user-guide/configure-ingress/) — Set up Gateway API or Ingress for production traffic.\n- [Configure Scaling Metrics](../user-guide/configure-scaling/) — Tune concurrency targets or switch to request-rate scaling.\n\n## Getting Help\n\n- [Kubernetes Slack](https://kubernetes.slack.com/archives/CKZJ36A5D) — `#keda` channel ([join here](https://slack.k8s.io))\n- [GitHub Issues](https://github.com/kedacore/http-add-on/issues) — Bug reports and feature requests\n- [GitHub Discussions](https://github.com/kedacore/http-add-on/discussions) — Questions and general conversation\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/_index.md",
    "content": "+++\ntitle = \"Operations\"\ndescription = \"HTTP Add-on infrastructure installation, configuration, and management\"\nweight = 400\n+++\n\nGuides for platform administrators installing and managing the HTTP Add-on.\n\n- **[Configure the Interceptor](configure-interceptor/)** — Timeouts, connection tuning, and scaling.\n- **[Configure Observability](configure-observability/)** — Prometheus metrics, OpenTelemetry tracing, and request logging.\n- **[Configure TLS](configure-tls/)** — TLS termination, certificates, and cipher suites.\n- **[Install the HTTP Add-on](installation/)** — Install, upgrade, and uninstall via Helm.\n- **[Migrate from HTTPScaledObject to InterceptorRoute](migrate-httpscaledobject-to-interceptorroute/)** — Upgrade existing resources to the v1beta1 API.\n- **[Troubleshooting](troubleshooting/)** — Debug request routing, inspect queue state, and profile performance.\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/configure-interceptor.md",
    "content": "+++\ntitle = \"Configure the Interceptor\"\ndescription = \"Timeout, connection, and scaling configuration for the interceptor proxy\"\n+++\n\nThe interceptor is the reverse proxy that sits in front of your application.\nThis page covers infrastructure-level settings configured via Helm values and environment variables.\n\n## Timeouts\n\nGlobal timeouts apply to all routes and serve as cluster-wide defaults.\nApplication developers can override these values per route on the `InterceptorRoute` — see [Configure Timeouts](../../user-guide/configure-timeouts/).\n\nSet global defaults via Helm values:\n\n```shell\nhelm install http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.requestTimeout=30s \\\n  --set interceptor.responseHeaderTimeout=15s \\\n  --set interceptor.readinessTimeout=20s\n```\n\n| Timeout         | Helm value                          | Env var                             | Default                                                            |\n| --------------- | ----------------------------------- | ----------------------------------- | ------------------------------------------------------------------ |\n| Request         | `interceptor.requestTimeout`        | `KEDA_HTTP_REQUEST_TIMEOUT`         | `0s` (disabled — no total deadline)                                |\n| Response header | `interceptor.responseHeaderTimeout` | `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | `300s`                                                             |\n| Readiness       | `interceptor.readinessTimeout`      | `KEDA_HTTP_READINESS_TIMEOUT`       | `0s` (disabled — readiness wait is bounded by the request timeout) |\n| Connect         | `interceptor.tcpConnectTimeout`     | `KEDA_HTTP_CONNECT_TIMEOUT`         | `500ms`                                                            |\n\n## Cold-start response header\n\nThe interceptor adds an `X-KEDA-HTTP-Cold-Start` response header to indicate whether a cold start occurred.\nThis header is enabled by default.\nTo disable it:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.extraEnvs.KEDA_HTTP_ENABLE_COLD_START_HEADER=false\n```\n\n## Connection tuning\n\nConfigure the interceptor's connection pool for backend services:\n\n| Helm value                        | Env var                             | Default | Description                                                                                                       |\n| --------------------------------- | ----------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------- |\n| `interceptor.maxIdleConns`        | `KEDA_HTTP_MAX_IDLE_CONNS`          | `1000`  | Maximum idle connections across all backend services. Increase this if you proxy to many backends.                |\n| `interceptor.maxIdleConnsPerHost` | `KEDA_HTTP_MAX_IDLE_CONNS_PER_HOST` | `200`   | Maximum idle connections per backend. Increase this if you observe frequent connection establishments under load. |\n\n## Interceptor scaling\n\nThe interceptor itself is auto-scaled by KEDA via a `ScaledObject` created by the Helm chart.\nConfigure the interceptor's scaling bounds:\n\n| Helm value                 | Default | Description                   |\n| -------------------------- | ------- | ----------------------------- |\n| `interceptor.replicas.min` | `3`     | Minimum interceptor replicas. |\n| `interceptor.replicas.max` | `50`    | Maximum interceptor replicas. |\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.replicas.min=<your-min> \\\n  --set interceptor.replicas.max=<your-max>\n```\n\n## What's Next\n\n- [Configure TLS](../configure-tls/) — TLS termination, certificates, and cipher suites.\n- [Configure Observability](../configure-observability/) — Prometheus metrics, OpenTelemetry tracing, and request logging.\n- [Environment Variables Reference](../../reference/environment-variables/) — all environment variables for each component.\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/configure-observability.md",
    "content": "+++\ntitle = \"Configure Observability\"\ndescription = \"Prometheus metrics, OpenTelemetry tracing, and request logging configuration for the interceptor\"\n+++\n\nThe interceptor exposes metrics and tracing data to help monitor HTTP traffic and scaling behavior.\nAll observability settings are configured via environment variables, set through the `interceptor.extraEnvs` Helm value.\n\n## Prometheus metrics\n\nThe interceptor exposes Prometheus metrics at `/metrics` on port `2223`.\nThis is enabled by default.\n\n| Env var                      | Default | Description                               |\n| ---------------------------- | ------- | ----------------------------------------- |\n| `OTEL_PROM_EXPORTER_ENABLED` | `true`  | Enable the Prometheus metrics endpoint.   |\n| `OTEL_PROM_EXPORTER_PORT`    | `2223`  | Port for the Prometheus metrics endpoint. |\n\nSee [Metrics Reference](../../reference/metrics/) for the full list of metrics and labels.\n\n## OpenTelemetry tracing\n\nEnable distributed tracing via OTLP:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_TRACES_ENABLED=true \\\n  --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=grpc \\\n  --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_ENDPOINT=http://<your-otel-collector>:4317\n```\n\nThe interceptor uses W3C TraceContext and Baggage propagation.\n\n| Env var                              | Default   | Description                                             |\n| ------------------------------------ | --------- | ------------------------------------------------------- |\n| `OTEL_EXPORTER_OTLP_TRACES_ENABLED`  | `false`   | Enable OTLP trace export.                               |\n| `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` | `console` | Exporter protocol (`grpc`, `http/protobuf`, `console`). |\n| `OTEL_EXPORTER_OTLP_ENDPOINT`        | —         | Collector endpoint URL.                                 |\n| `OTEL_EXPORTER_OTLP_HEADERS`         | —         | Authentication headers (e.g., `api-key=<token>`).       |\n| `OTEL_EXPORTER_OTLP_TRACES_TIMEOUT`  | `10s`     | Timeout for trace export requests.                      |\n\n## OpenTelemetry metrics\n\nEnable OTLP metrics export alongside or instead of Prometheus:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_METRICS_ENABLED=true \\\n  --set interceptor.extraEnvs.OTEL_EXPORTER_OTLP_ENDPOINT=http://<your-otel-collector>:4317\n```\n\n| Env var                              | Default | Description                                         |\n| ------------------------------------ | ------- | --------------------------------------------------- |\n| `OTEL_EXPORTER_OTLP_METRICS_ENABLED` | `false` | Enable OTLP metrics export.                         |\n| `OTEL_EXPORTER_OTLP_ENDPOINT`        | —       | Collector endpoint URL (shared with traces if set). |\n| `OTEL_EXPORTER_OTLP_HEADERS`         | —       | Authentication headers (shared with traces if set). |\n| `OTEL_METRIC_EXPORT_INTERVAL`        | `60s`   | Interval between periodic metric exports.           |\n\n## Request logging\n\nEnable Combined Log Format request logging:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.extraEnvs.KEDA_HTTP_LOG_REQUESTS=true\n```\n\n## What's Next\n\n- [Metrics Reference](../../reference/metrics/) — detailed Prometheus metric definitions.\n- [Environment Variables Reference](../../reference/environment-variables/) — all observability-related environment variables.\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/configure-tls.md",
    "content": "+++\ntitle = \"Configure TLS\"\ndescription = \"TLS termination, certificates, cipher suites, and SNI configuration for the interceptor proxy\"\n+++\n\n> **Note:** This page has not been fully verified against the current implementation.\n> Configuration values, environment variable names, or default values may be inaccurate or incomplete.\n> If you find an issue, please [open a GitHub issue](https://github.com/kedacore/keda-docs/issues/new) or submit a pull request.\n\nThe interceptor can terminate TLS for incoming connections.\nAll TLS settings are configured via Helm values and environment variables.\n\n## Enable TLS termination\n\nEnable TLS on the interceptor proxy:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.tls.enabled=true \\\n  --set interceptor.tls.certSecret=<your-tls-secret>\n```\n\nThe interceptor loads TLS certificates from a Kubernetes Secret mounted at `/certs`.\nThe Secret must contain `tls.crt` and `tls.key` entries.\n\n## TLS settings\n\n| Helm value                         | Env var                                 | Default                        | Description                                                              |\n| ---------------------------------- | --------------------------------------- | ------------------------------ | ------------------------------------------------------------------------ |\n| `interceptor.tls.enabled`          | `KEDA_HTTP_PROXY_TLS_ENABLED`           | `false`                        | Enable TLS on the proxy.                                                 |\n| `interceptor.tls.port`             | `KEDA_HTTP_PROXY_TLS_PORT`              | `8443`                         | Port the TLS proxy listens on.                                           |\n| `interceptor.tls.certSecret`       | —                                       | `keda-tls-certs`               | Name of the Kubernetes Secret containing the TLS certificate and key.    |\n| `interceptor.tls.certPath`         | `KEDA_HTTP_PROXY_TLS_CERT_PATH`         | `/certs/tls.crt`               | Path to the certificate file.                                            |\n| `interceptor.tls.keyPath`          | `KEDA_HTTP_PROXY_TLS_KEY_PATH`          | `/certs/tls.key`               | Path to the private key file.                                            |\n| `interceptor.tls.minVersion`       | `KEDA_HTTP_PROXY_TLS_MIN_VERSION`       | Go default (TLS 1.2)           | Minimum TLS version (`\"1.2\"` or `\"1.3\"`).                                |\n| `interceptor.tls.maxVersion`       | `KEDA_HTTP_PROXY_TLS_MAX_VERSION`       | Go default (highest supported) | Maximum TLS version (`\"1.2\"` or `\"1.3\"`).                                |\n| `interceptor.tls.cipherSuites`     | `KEDA_HTTP_PROXY_TLS_CIPHER_SUITES`     | Go defaults                    | Comma-separated list of cipher suite names.                              |\n| `interceptor.tls.curvePreferences` | `KEDA_HTTP_PROXY_TLS_CURVE_PREFERENCES` | Go defaults                    | Comma-separated list of elliptic curve names (e.g., `X25519,CurveP256`). |\n| `interceptor.tls.skipVerify`       | `KEDA_HTTP_PROXY_TLS_SKIP_VERIFY`       | `false`                        | Skip TLS verification for upstream (backend) connections.                |\n\n## SNI-based certificate selection\n\nThe interceptor supports SNI-based certificate selection when multiple certificate/key pairs are loaded via the `KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHS` environment variable.\nSet this to a comma-separated list of paths containing additional certificate/key pairs.\n\n## What's Next\n\n- [Environment Variables Reference](../../reference/environment-variables/) — all TLS-related environment variables.\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/installation.md",
    "content": "+++\ntitle = \"Install the HTTP Add-on\"\ndescription = \"HTTP Add-on installation, upgrade, and removal via Helm\"\nweight = 1\n+++\n\n## Prerequisites\n\nBefore installing the HTTP Add-on, ensure you have:\n\n- A Kubernetes cluster (tested against the three most recent minor versions)\n- [Helm 3](https://helm.sh/docs/intro/install/)\n- KEDA core installed ([deployment guide](https://keda.sh/docs/deploy/))\n\nIf you have not installed KEDA yet, run:\n\n```shell\nhelm repo add kedacore https://kedacore.github.io/charts\nhelm repo update\nhelm install keda kedacore/keda --namespace keda --create-namespace\n```\n\n## Install\n\n1. Add the KEDA Helm repository (if you have not already):\n\n   ```shell\n   helm repo add kedacore https://kedacore.github.io/charts\n   helm repo update\n   ```\n\n2. Install the HTTP Add-on into the same namespace as KEDA:\n\n   ```shell\n   helm install http-add-on kedacore/keda-add-ons-http --namespace keda\n   ```\n\n3. Verify the installation:\n\n   ```shell\n   kubectl get pods -n keda\n   ```\n\n   You should see pods for the operator, interceptor, and scaler components in a `Running` state.\n\n### Helm Values to Consider\n\nThe following values are commonly configured at install time.\nPass them with `--set` or in a values file (`-f values.yaml`).\n\n| Value                      | Description                                                                       | Default |\n| -------------------------- | --------------------------------------------------------------------------------- | ------- |\n| `interceptor.replicas.min` | Minimum number of interceptor replicas                                            | `3`     |\n| `interceptor.replicas.max` | Maximum number of interceptor replicas                                            | `50`    |\n| `operator.watchNamespace`  | Restrict the operator to a single namespace (empty string watches all namespaces) | `\"\"`    |\n\nFor the full list of configuration options, see the [http-add-on chart](https://github.com/kedacore/charts/tree/main/http-add-on#configuration).\n\n## Upgrade\n\nTo upgrade to a newer version of the HTTP Add-on:\n\n```shell\nhelm repo update\nhelm upgrade http-add-on kedacore/keda-add-ons-http --namespace keda\n```\n\nThe CRDs are included as Helm templates (not in the `crds/` directory), so they are updated automatically during `helm upgrade`.\n\n## Uninstall\n\n1. Remove the HTTP Add-on Helm release:\n\n   ```shell\n   helm uninstall http-add-on --namespace keda\n   ```\n\n2. CRDs are **not** automatically removed on uninstall. To remove them manually:\n\n   ```shell\n   kubectl delete crd httpscaledobjects.http.keda.sh interceptorroutes.http.keda.sh\n   ```\n\n   > **Warning:** Deleting the CRDs removes all `HTTPScaledObject` and `InterceptorRoute` resources in the cluster. Make sure you no longer need them before proceeding.\n\n## Namespace-Scoped Installation\n\nBy default, the operator watches all namespaces for `HTTPScaledObject` and `InterceptorRoute` resources.\nTo restrict the operator to a single namespace:\n\n```shell\nhelm install http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set operator.watchNamespace=<your-namespace>\n```\n\nFor the full list of configuration options, see the [http-add-on chart](https://github.com/kedacore/charts/tree/main/http-add-on#configuration).\n\n## What's Next\n\n- [Autoscale an App](../../user-guide/autoscale-an-app/) — Create a ScaledObject and InterceptorRoute for your service.\n- [Configure the Interceptor](../configure-interceptor/) — Timeouts, connection tuning, and scaling.\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/migrate-httpscaledobject-to-interceptorroute.md",
    "content": "+++\ntitle = \"Migrate from HTTPScaledObject to InterceptorRoute\"\ndescription = \"How to migrate existing HTTPScaledObject resources to the InterceptorRoute API\"\n+++\n\nThis guide shows you how to migrate existing `HTTPScaledObject` (v1alpha1) resources to the `InterceptorRoute` (v1beta1) API.\n\n## Prerequisites\n\n- KEDA HTTP Add-on v0.14.0 or later deployed on the cluster\n- `kubectl` access to the cluster\n- Existing `HTTPScaledObject` resources to migrate\n\n## What changed\n\nThe `InterceptorRoute` API replaces `HTTPScaledObject` with a cleaner separation of concerns.\n\n- **Manual ScaledObject management:**\n  The `InterceptorRoute` controller no longer creates a KEDA `ScaledObject` for you.\n  You create and manage it yourself, with access to all supported KEDA ScaledObject fields.\n- **Multiple routing rules:**\n  A new `rules[]` structure lets you define multiple routing rules on a single resource, each with its own hosts, paths, and headers.\n- **Target reference for routing only:**\n  The target reference contains only `service` and `port`/`portName`.\n  Workload fields (`name`, `apiVersion`, `kind`) move to the `ScaledObject` where they belong.\n- **Flexible scaling metrics:**\n  Concurrency and request rate can be used independently or together.\n  When both are set, KEDA scales based on whichever metric demands more replicas.\n- **Granular timeouts:**\n  A new `request` timeout controls the full request lifecycle.\n  `conditionWait` is renamed to `readiness` for clarity.\n- **`targetValue` is required:**\n  On `HTTPScaledObject`, `targetValue` defaulted to `100` when omitted.\n  On `InterceptorRoute`, `targetValue` must be set explicitly.\n  If your `HTTPScaledObject` relied on the default, add `targetValue: 100` (or your preferred value) when migrating.\n- **Scaling fields move to ScaledObject:**\n  `replicas`, `targetPendingRequests`, `scaledownPeriod`, and `initialCooldownPeriod` are configured on the KEDA `ScaledObject` directly.\n\n## Convert an HTTPScaledObject to an InterceptorRoute\n\nThe migration is a direct field-by-field conversion.\nThe [Apply the migration without downtime](#apply-the-migration-without-downtime) section below shows how to perform the switchover without interrupting traffic.\n\n### Before: HTTPScaledObject\n\n```yaml\napiVersion: http.keda.sh/v1alpha1\nkind: HTTPScaledObject\nmetadata:\n  name: my-app\n  namespace: default\nspec:\n  hosts:\n    - app.example.com\n  pathPrefixes:\n    - /api\n    - /health\n  headers:\n    - name: X-Custom-Header\n      value: \"my-value\"\n  scaleTargetRef:\n    name: my-app\n    kind: Deployment\n    apiVersion: apps/v1\n    service: my-app-svc\n    port: 8080\n  coldStartTimeoutFailoverRef:\n    service: fallback-svc\n    port: 8080\n    timeoutSeconds: 45\n  replicas:\n    min: 0\n    max: 10\n  scalingMetric:\n    concurrency:\n      targetValue: 50\n  timeouts:\n    conditionWait: 30s\n    responseHeader: 10s\n  scaledownPeriod: 120\n```\n\n### After: InterceptorRoute and ScaledObject\n\nThe single `HTTPScaledObject` becomes two resources: an `InterceptorRoute` for routing and an independently managed `ScaledObject` for scaling.\n\n**InterceptorRoute:**\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\n  namespace: default\nspec:\n  target:\n    service: my-app-svc\n    port: 8080\n  coldStart:\n    fallback:\n      service: fallback-svc\n      port: 8080\n  rules:\n    - hosts:\n        - app.example.com\n      paths:\n        - value: /api\n        - value: /health\n      headers:\n        - name: X-Custom-Header\n          value: \"my-value\"\n  scalingMetric:\n    concurrency:\n      targetValue: 50\n  timeouts:\n    readiness: 45s\n    responseHeader: 10s\n```\n\n**ScaledObject:**\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: my-app\n  namespace: default\nspec:\n  scaleTargetRef:\n    name: my-app\n    kind: Deployment\n    apiVersion: apps/v1\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  cooldownPeriod: 120\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: \"keda-add-ons-http-external-scaler.keda:9090\"\n        interceptorRoute: \"my-app\"\n```\n\nNote the following conversions:\n\n1. `scaleTargetRef` becomes `target` with only `service` and `port`/`portName`.\n2. `hosts`, `pathPrefixes`, and `headers` move into a `rules[]` entry.\n3. `pathPrefixes` entries become `paths` entries, each with a `value` field.\n4. `coldStartTimeoutFailoverRef` splits: the service reference moves to `coldStart.fallback`, and `timeoutSeconds` moves to `timeouts.readiness` as a duration string (`\"45s\"`).\n5. `replicas`, `scaledownPeriod`, and `initialCooldownPeriod` move to the `ScaledObject`.\n6. The workload reference (`name`, `apiVersion`, `kind`) moves to the `ScaledObject`'s `scaleTargetRef`.\n\n## Apply the migration without downtime\n\nThe `HTTPScaledObject` controller sets an owner reference on the KEDA `ScaledObject` it creates.\nDeleting the `HTTPScaledObject` triggers Kubernetes garbage collection, which cascade-deletes the owned `ScaledObject`.\nTo prevent this, add the `httpscaledobject.keda.sh/orphan-scaledobject` annotation to the `HTTPScaledObject` before deleting it.\nThe controller removes the owner reference from the `ScaledObject`, so it survives deletion.\n\nSet these environment variables before running the commands:\n\n```bash\nNAME=my-app\nNAMESPACE=default\n```\n\n1. Annotate the `HTTPScaledObject` to orphan its `ScaledObject`:\n\n   ```bash\n   kubectl annotate httpscaledobject $NAME -n $NAMESPACE \\\n     httpscaledobject.keda.sh/orphan-scaledobject=true\n   ```\n\n   The controller removes the owner reference from the `ScaledObject`.\n   Verify that the owner reference was removed:\n\n   ```bash\n   kubectl get scaledobject $NAME -n $NAMESPACE \\\n     -o jsonpath='{.metadata.ownerReferences}'\n   ```\n\n   The output is empty when the owner reference has been removed.\n\n2. Create the `InterceptorRoute`:\n\n   ```bash\n   kubectl apply -f interceptor-route.yaml\n   ```\n\n   When the `InterceptorRoute` shares the same namespace and name as the `HTTPScaledObject`, the routing table automatically gives the `InterceptorRoute` precedence and skips the `HTTPScaledObject`.\n\n3. Update the `ScaledObject` trigger metadata.\n   The auto-created `ScaledObject` references the `HTTPScaledObject` by name in its trigger metadata.\n   Replace `httpScaledObject` with `interceptorRoute` so the external scaler resolves metrics from the `InterceptorRoute`:\n\n   ```bash\n   kubectl patch scaledobject $NAME -n $NAMESPACE --type=json \\\n     -p '[{\"op\": \"remove\", \"path\": \"/spec/triggers/0/metadata/httpScaledObject\"},\n          {\"op\": \"add\", \"path\": \"/spec/triggers/0/metadata/interceptorRoute\", \"value\": \"'$NAME'\"}]'\n   ```\n\n   Also compare the remaining fields with the ScaledObject YAML from the conversion example and adjust `minReplicaCount`, `maxReplicaCount`, or `cooldownPeriod` as needed.\n\n4. Verify the `ScaledObject` is still present and active:\n\n   ```bash\n   kubectl get scaledobject $NAME -n $NAMESPACE\n   ```\n\n5. Delete the old `HTTPScaledObject`:\n\n   ```bash\n   kubectl delete httpscaledobject $NAME -n $NAMESPACE\n   ```\n\n   The `ScaledObject` remains in the cluster because the owner reference was removed in step 1.\n\n> **GitOps:** In one commit, add the orphan annotation to the `HTTPScaledObject` manifest, add the `InterceptorRoute` manifest, and update the `ScaledObject` trigger metadata (`httpScaledObject` → `interceptorRoute`).\n> In the next commit, remove the `HTTPScaledObject` manifest.\n\n## Field mapping\n\n### HTTPScaledObject → InterceptorRoute\n\n| HTTPScaledObject field                            | InterceptorRoute field                                  |\n| ------------------------------------------------- | ------------------------------------------------------- |\n| `spec.hosts`                                      | `spec.rules[].hosts`                                    |\n| `spec.pathPrefixes`                               | `spec.rules[].paths[].value`                            |\n| `spec.headers`                                    | `spec.rules[].headers`                                  |\n| `spec.scaleTargetRef.service`                     | `spec.target.service`                                   |\n| `spec.scaleTargetRef.port`                        | `spec.target.port`                                      |\n| `spec.scaleTargetRef.portName`                    | `spec.target.portName`                                  |\n| `spec.coldStartTimeoutFailoverRef.service`        | `spec.coldStart.fallback.service`                       |\n| `spec.coldStartTimeoutFailoverRef.port`           | `spec.coldStart.fallback.port`                          |\n| `spec.coldStartTimeoutFailoverRef.portName`       | `spec.coldStart.fallback.portName`                      |\n| `spec.coldStartTimeoutFailoverRef.timeoutSeconds` | `spec.timeouts.readiness` (as `Duration`, e.g. `\"30s\"`) |\n| `spec.scalingMetric.concurrency.targetValue`      | `spec.scalingMetric.concurrency.targetValue`            |\n| `spec.scalingMetric.requestRate.targetValue`      | `spec.scalingMetric.requestRate.targetValue`            |\n| `spec.scalingMetric.requestRate.window`           | `spec.scalingMetric.requestRate.window`                 |\n| `spec.scalingMetric.requestRate.granularity`      | `spec.scalingMetric.requestRate.granularity`            |\n| `spec.targetPendingRequests`                      | `spec.scalingMetric`                                    |\n| `spec.timeouts.conditionWait`                     | `spec.timeouts.readiness`                               |\n| `spec.timeouts.responseHeader`                    | `spec.timeouts.responseHeader`                          |\n| _(new)_                                           | `spec.timeouts.request`                                 |\n\n### HTTPScaledObject → ScaledObject\n\n| HTTPScaledObject field           | ScaledObject field               |\n| -------------------------------- | -------------------------------- |\n| `spec.scaleTargetRef.name`       | `spec.scaleTargetRef.name`       |\n| `spec.scaleTargetRef.apiVersion` | `spec.scaleTargetRef.apiVersion` |\n| `spec.scaleTargetRef.kind`       | `spec.scaleTargetRef.kind`       |\n| `spec.replicas.min`              | `spec.minReplicaCount`           |\n| `spec.replicas.max`              | `spec.maxReplicaCount`           |\n| `spec.scaledownPeriod`           | `spec.cooldownPeriod`            |\n| `spec.initialCooldownPeriod`     | `spec.initialCooldownPeriod`     |\n\n## What's Next\n\n- [Configure Routing Rules](../../user-guide/configure-routing/) — multiple rules, host, path, and header matching on an InterceptorRoute.\n- [Configure Scaling Metrics](../../user-guide/configure-scaling/) — concurrency, request rate, and combined metric configuration.\n- [InterceptorRoute Reference](../../reference/interceptorroute/) — full API specification.\n- [KEDA ScaledObject documentation](https://keda.sh/docs/latest/concepts/scaling-deployments/) — scaling configuration options.\n"
  },
  {
    "path": "content/http-add-on/0.14/operations/troubleshooting.md",
    "content": "+++\ntitle = \"Troubleshooting\"\ndescription = \"Request routing, queue state, and component performance troubleshooting\"\n+++\n\n## Queue inspection\n\nThe interceptor exposes a `/queue` endpoint on its admin service (port `9090` by default) that returns the current pending request counts per route as JSON.\n\n```shell\nkubectl port-forward -n keda svc/keda-add-ons-http-interceptor-admin 9090\n```\n\n```shell\ncurl -X GET localhost:9090/queue\n```\n\nThe response is a JSON object keyed by `namespace/route-name`, with concurrency and request count for each route:\n\n```json\n{\n  \"default/my-app\": { \"Concurrency\": 3, \"RequestCount\": 42 },\n  \"demo/sample-app\": { \"Concurrency\": 0, \"RequestCount\": 0 }\n}\n```\n\nThe endpoint shows raw counts from the interceptor.\nRequest rate (RPS) is calculated by the scaler component based on these counts and the configured window — it is not part of this response.\n\n## Profiling\n\nEnable pprof profiling on the interceptor or scaler by setting the `PROFILING_BIND_ADDRESS` environment variable:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set interceptor.extraEnvs.PROFILING_BIND_ADDRESS=0.0.0.0:6060\n```\n\nFor the operator, use the `--profiling-bind-address` flag instead:\n\n```shell\nhelm upgrade http-add-on kedacore/keda-add-ons-http \\\n  --namespace keda \\\n  --set operator.extraArgs.profiling-bind-address=:6060\n```\n\nOnce enabled, collect profiles with `go tool pprof`:\n\n```shell\nkubectl port-forward -n keda deploy/keda-add-ons-http-interceptor 6060\ngo tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap\n```\n\n## Getting Help\n\nIf you cannot resolve the issue, the following channels are available:\n\n- [Kubernetes Slack](https://kubernetes.slack.com/archives/CKZJ36A5D) — `#keda` channel ([join here](https://slack.k8s.io))\n- [GitHub Issues](https://github.com/kedacore/http-add-on/issues) — Bug reports and feature requests\n- [GitHub Discussions](https://github.com/kedacore/http-add-on/discussions) — Questions and general conversation\n\n## What's Next\n\n- [Configure the Interceptor](../configure-interceptor/) — Timeouts, connection tuning, and scaling.\n- [Environment Variables Reference](../../reference/environment-variables/) — all environment variables for each component.\n- [Metrics Reference](../../reference/metrics/) — Prometheus metric definitions for monitoring.\n"
  },
  {
    "path": "content/http-add-on/0.14/reference/_index.md",
    "content": "+++\ntitle = \"Reference\"\ndescription = \"API specifications, environment variables, and metrics\"\nweight = 500\n+++\n\n- **[Environment Variables](environment-variables/)** — Environment variables for each component.\n- **[HTTPScaledObject](httpscaledobject/)** — HTTPScaledObject CRD API reference (v1alpha1, deprecated).\n- **[InterceptorRoute](interceptorroute/)** — InterceptorRoute CRD API reference (v1beta1).\n- **[Metrics](metrics/)** — Prometheus metrics exposed by the interceptor.\n"
  },
  {
    "path": "content/http-add-on/0.14/reference/environment-variables.md",
    "content": "+++\ntitle = \"Environment Variables\"\ndescription = \"Reference for all environment variables accepted by each component\"\n+++\n\nEnvironment variables configure runtime behavior for each HTTP Add-on component.\nThese are set via the `extraEnvs` Helm value for each component or directly in the container spec.\n\n## Interceptor\n\n### Serving\n\n| Variable                                            | Default      | Description                                                                                   |\n| --------------------------------------------------- | ------------ | --------------------------------------------------------------------------------------------- |\n| `KEDA_HTTP_PROXY_PORT`                              | _(required)_ | Port for the public proxy server.                                                             |\n| `KEDA_HTTP_ADMIN_PORT`                              | _(required)_ | Port for the internal admin server (metrics RPC endpoint for the scaler).                     |\n| `KEDA_HTTP_WATCH_NAMESPACE`                         | `\"\"`         | Namespace to watch for HTTPScaledObjects and InterceptorRoutes. Empty watches all namespaces. |\n| `KEDA_HTTP_SCALER_CONFIG_MAP_INFORMER_RSYNC_PERIOD` | `60m`        | Resync interval for the controller-runtime cache.                                             |\n| `KEDA_HTTP_ENABLE_COLD_START_HEADER`                | `true`       | When enabled, the interceptor adds the `X-KEDA-HTTP-Cold-Start` response header.              |\n| `KEDA_HTTP_LOG_REQUESTS`                            | `false`      | Enable logging of incoming requests.                                                          |\n\n### Timeouts\n\n| Variable                            | Default | Description                                                                                                                                                                                                                                         |\n| ----------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `KEDA_HTTP_REQUEST_TIMEOUT`         | `0s`    | Total request lifecycle deadline. `0s` disables the deadline.                                                                                                                                                                                       |\n| `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | `300s`  | Time to wait for response headers from the backend after the request is sent. `0s` disables the deadline.                                                                                                                                           |\n| `KEDA_HTTP_READINESS_TIMEOUT`       | `0s`    | Time to wait for the backing workload to reach 1 or more replicas. `0s` disables the dedicated readiness deadline, giving the full request budget to cold starts. When a fallback service is configured and this is `0s`, a 30s default is applied. |\n| `KEDA_HTTP_CONNECT_TIMEOUT`         | `500ms` | Per-attempt TCP dial timeout. Bounded by the request context deadline.                                                                                                                                                                              |\n| `KEDA_HTTP_MAX_IDLE_CONNS`          | `1000`  | Maximum idle connections in the connection pool across all backend services.                                                                                                                                                                        |\n| `KEDA_HTTP_MAX_IDLE_CONNS_PER_HOST` | `200`   | Maximum idle connections per backend service.                                                                                                                                                                                                       |\n| `KEDA_HTTP_FORCE_HTTP2`             | `false` | Whether to force HTTP/2 for all proxied requests.                                                                                                                                                                                                   |\n\n#### Deprecated timeout variables\n\nThese deprecated variables are still accepted.\nWhen set, they take precedence over their replacements.\n\n| Deprecated Variable            | Replacement                         | Description                                                       |\n| ------------------------------ | ----------------------------------- | ----------------------------------------------------------------- |\n| `KEDA_CONDITION_WAIT_TIMEOUT`  | `KEDA_HTTP_READINESS_TIMEOUT`       | Time to wait for the backing workload to have 1 or more replicas. |\n| `KEDA_RESPONSE_HEADER_TIMEOUT` | `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | Time to wait for response headers from the backend.               |\n\n### TLS\n\n| Variable                                | Default          | Description                                                                                     |\n| --------------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------- |\n| `KEDA_HTTP_PROXY_TLS_ENABLED`           | `false`          | Enable TLS on the proxy server.                                                                 |\n| `KEDA_HTTP_PROXY_TLS_CERT_PATH`         | `/certs/tls.crt` | Path to the TLS certificate file.                                                               |\n| `KEDA_HTTP_PROXY_TLS_KEY_PATH`          | `/certs/tls.key` | Path to the TLS private key file.                                                               |\n| `KEDA_HTTP_PROXY_TLS_CERT_STORE_PATHS`  | `\"\"`             | Comma-separated list of paths to certificate/key pairs.                                         |\n| `KEDA_HTTP_PROXY_TLS_SKIP_VERIFY`       | `false`          | Skip TLS verification for upstream connections.                                                 |\n| `KEDA_HTTP_PROXY_TLS_PORT`              | `8443`           | Port for the TLS proxy server.                                                                  |\n| `KEDA_HTTP_PROXY_TLS_MIN_VERSION`       | `\"\"`             | Minimum TLS version (`1.2` or `1.3`). Empty uses the Go default (TLS 1.2).                      |\n| `KEDA_HTTP_PROXY_TLS_MAX_VERSION`       | `\"\"`             | Maximum TLS version (`1.2` or `1.3`). Empty uses the highest version supported by `crypto/tls`. |\n| `KEDA_HTTP_PROXY_TLS_CIPHER_SUITES`     | `\"\"`             | Comma-separated list of TLS cipher suite names. Empty uses Go defaults.                         |\n| `KEDA_HTTP_PROXY_TLS_CURVE_PREFERENCES` | `\"\"`             | Comma-separated list of elliptic curve names. Empty uses Go defaults.                           |\n\n### Metrics\n\n| Variable                             | Default | Description                                          |\n| ------------------------------------ | ------- | ---------------------------------------------------- |\n| `OTEL_PROM_EXPORTER_ENABLED`         | `true`  | Enable the Prometheus metrics exporter.              |\n| `OTEL_PROM_EXPORTER_PORT`            | `2223`  | Port for the Prometheus-compatible metrics endpoint. |\n| `OTEL_EXPORTER_OTLP_METRICS_ENABLED` | `false` | Enable the OTLP metrics exporter.                    |\n\n### Tracing\n\n| Variable                             | Default   | Description                                                                  |\n| ------------------------------------ | --------- | ---------------------------------------------------------------------------- |\n| `OTEL_EXPORTER_OTLP_TRACES_ENABLED`  | `false`   | Enable OpenTelemetry trace export.                                           |\n| `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` | `console` | Trace exporter protocol. Must be one of: `console`, `http/protobuf`, `grpc`. |\n\n### Profiling\n\n| Variable                 | Default | Description                                                             |\n| ------------------------ | ------- | ----------------------------------------------------------------------- |\n| `PROFILING_BIND_ADDRESS` | `\"\"`    | Address (`host:port`) for the pprof endpoint. Empty disables profiling. |\n\n## Scaler\n\n| Variable                                            | Default      | Description                                                                         |\n| --------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------- |\n| `KEDA_HTTP_SCALER_PORT`                             | `8080`       | Port for the KEDA-compatible gRPC external scaler interface.                        |\n| `KEDA_HTTP_SCALER_TARGET_ADMIN_NAMESPACE`           | _(required)_ | Namespace where the scaler and interceptors are running.                            |\n| `KEDA_HTTP_SCALER_TARGET_ADMIN_SERVICE`             | _(required)_ | Name of the interceptor admin Service to issue metrics RPC requests to.             |\n| `KEDA_HTTP_SCALER_TARGET_ADMIN_DEPLOYMENT`          | _(required)_ | Name of the interceptor Deployment to issue metrics RPC requests to.                |\n| `KEDA_HTTP_SCALER_TARGET_ADMIN_PORT`                | _(required)_ | Port on the interceptor admin Service for metrics RPC requests.                     |\n| `KEDA_HTTP_SCALER_CONFIG_MAP_INFORMER_RSYNC_PERIOD` | `60m`        | Resync interval for the controller-runtime cache.                                   |\n| `KEDA_HTTP_QUEUE_TICK_DURATION`                     | `500ms`      | Duration between queue polling ticks.                                               |\n| `KEDA_HTTP_SCALER_STREAM_INTERVAL_MS`               | `200`        | Interval in milliseconds between stream ticks for `IsActive` communication to KEDA. |\n| `PROFILING_BIND_ADDRESS`                            | `\"\"`         | Address (`host:port`) for the pprof endpoint. Empty disables profiling.             |\n\n## Operator\n\n| Variable                                            | Default      | Description                                                                         |\n| --------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------- |\n| `KEDA_HTTP_OPERATOR_EXTERNAL_SCALER_SERVICE`        | _(required)_ | Name of the Kubernetes Service for the external scaler.                             |\n| `KEDA_HTTP_OPERATOR_EXTERNAL_SCALER_PORT`           | `8091`       | Port for the external scaler Service.                                               |\n| `KEDA_HTTP_OPERATOR_NAMESPACE`                      | `\"\"`         | Namespace in which the operator is running.                                         |\n| `KEDA_HTTP_OPERATOR_WATCH_NAMESPACE`                | `\"\"`         | Namespace to watch for resources. Empty watches all namespaces.                     |\n| `KEDA_HTTP_OPERATOR_LEADER_ELECTION_LEASE_DURATION` | _(unset)_    | Leader election lease duration. When unset, the controller-runtime default is used. |\n| `KEDA_HTTP_OPERATOR_LEADER_ELECTION_RENEW_DEADLINE` | _(unset)_    | Leader election renew deadline. When unset, the controller-runtime default is used. |\n| `KEDA_HTTP_OPERATOR_LEADER_ELECTION_RETRY_PERIOD`   | _(unset)_    | Leader election retry period. When unset, the controller-runtime default is used.   |\n"
  },
  {
    "path": "content/http-add-on/0.14/reference/httpscaledobject.md",
    "content": "+++\ntitle = \"HTTPScaledObject (Deprecated)\"\ndescription = \"Field-by-field API reference for the HTTPScaledObject custom resource\"\n+++\n\n> **Deprecated:** HTTPScaledObject (v1alpha1) is deprecated.\n> [InterceptorRoute](../interceptorroute/) (v1beta1) is the current API.\n> See [Migrate from HTTPScaledObject to InterceptorRoute](../../operations/migrate-httpscaledobject-to-interceptorroute/) to upgrade.\n\n|                 |                         |\n| --------------- | ----------------------- |\n| **API version** | `http.keda.sh/v1alpha1` |\n| **Kind**        | `HTTPScaledObject`      |\n| **Short name**  | `httpso`                |\n| **Scope**       | Namespaced              |\n\n## Example\n\n```yaml\napiVersion: http.keda.sh/v1alpha1\nkind: HTTPScaledObject\nmetadata:\n  name: my-app\n  namespace: default\nspec:\n  hosts:\n    - app.example.com\n  pathPrefixes:\n    - /api\n  scaleTargetRef:\n    name: my-app\n    service: my-app-svc\n    port: 8080\n  replicas:\n    min: 0\n    max: 10\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n```\n\n## Annotations\n\n| Annotation                                            | Value    | Description                                                                                                                                                          |\n| ----------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `httpscaledobject.keda.sh/skip-scaledobject-creation` | `\"true\"` | Skip automatic ScaledObject creation. Set this when you want to integrate the HTTP scaler with other KEDA scalers in a single ScaledObject that you manage yourself. |\n| `httpscaledobject.keda.sh/orphan-scaledobject`        | `\"true\"` | When the HTTPScaledObject is deleted, leave the generated ScaledObject in place instead of deleting it.                                                              |\n\nWhen `skip-scaledobject-creation` is set to `\"true\"`, the operator does not create or manage a ScaledObject.\nYou can then create your own ScaledObject and add the HTTP external scaler as one of the triggers:\n\n```yaml\ntriggers:\n  - type: external-push\n    metadata:\n      httpScaledObject: <your-httpso-name>\n      scalerAddress: keda-add-ons-http-external-scaler.keda:9090\n```\n\n> **Note:** The InterceptorRoute API does not use this annotation.\n> InterceptorRoute separates routing from scaling by design — you always create your own ScaledObject.\n\n## `spec`\n\n| Field                         | Type                                                             | Required | Default | Description                                                                                                                                                           |\n| ----------------------------- | ---------------------------------------------------------------- | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `hosts`                       | `[]string`                                                       | No       |         | Hostnames to route. Requests whose `Host` header matches any entry (combined with `pathPrefixes`) are routed to the target.                                           |\n| `pathPrefixes`                | `[]string`                                                       | No       |         | URL path prefixes to match. Combined with `hosts` for routing.                                                                                                        |\n| `headers`                     | [`[]Header`](#header)                                            | No       |         | Custom headers for routing. After `hosts` and `pathPrefixes` match, requests must also match all listed headers. The interceptor uses the most specific header match. |\n| `scaleTargetRef`              | [`ScaleTargetRef`](#scaletargetref)                              | Yes      |         | The target workload and service to scale and route to.                                                                                                                |\n| `coldStartTimeoutFailoverRef` | [`*ColdStartTimeoutFailoverRef`](#coldstarttimeoutfailoverref)   | No       |         | Failover service to route to when the target is not available during cold start.                                                                                      |\n| `replicas`                    | [`*ReplicaStruct`](#replicastruct)                               | No       |         | Minimum and maximum replica counts.                                                                                                                                   |\n| `targetPendingRequests`       | `*int32`                                                         | No       | `100`   | **Deprecated.** Use `scalingMetric` instead. Target metric value for the HPA.                                                                                         |\n| `scaledownPeriod`             | `*int32`                                                         | No       | `300`   | Cooldown period in seconds before resources scale down.                                                                                                               |\n| `initialCooldownPeriod`       | `*int32`                                                         | No       | `0`     | Initial period in seconds before scaling begins.                                                                                                                      |\n| `scalingMetric`               | [`*ScalingMetricSpec`](#scalingmetricspec)                       | No       |         | Configuration for the scaling metric. When empty, concurrency-based scaling is used.                                                                                  |\n| `timeouts`                    | [`*HTTPScaledObjectTimeoutsSpec`](#httpscaledobjecttimeoutsspec) | No       |         | Per-object timeout overrides for the global interceptor timeouts.                                                                                                     |\n\n### `ScaleTargetRef`\n\n| Field        | Type     | Required | Default | Description                                                     |\n| ------------ | -------- | -------- | ------- | --------------------------------------------------------------- |\n| `name`       | `string` | No       |         | Name of the Deployment or StatefulSet to scale.                 |\n| `apiVersion` | `string` | No       |         | API version of the target workload.                             |\n| `kind`       | `string` | No       |         | Kind of the target workload.                                    |\n| `service`    | `string` | Yes      |         | Name of the Kubernetes Service to route to.                     |\n| `port`       | `int32`  | No       |         | Port number on the Service. Mutually exclusive with `portName`. |\n| `portName`   | `string` | No       |         | Named port on the Service. Mutually exclusive with `port`.      |\n\n**Validation:** Exactly one of `port` or `portName` must be set.\n\n### `Header`\n\n| Field   | Type      | Required | Default | Description                                                                                     |\n| ------- | --------- | -------- | ------- | ----------------------------------------------------------------------------------------------- |\n| `name`  | `string`  | Yes      |         | Name of the HTTP header. Minimum length: 1.                                                     |\n| `value` | `*string` | No       |         | Value to match (exact match). If omitted, the header must be present but any value is accepted. |\n\n### `ReplicaStruct`\n\n| Field | Type     | Required | Default | Description            |\n| ----- | -------- | -------- | ------- | ---------------------- |\n| `min` | `*int32` | No       | `0`     | Minimum replica count. |\n| `max` | `*int32` | No       | `100`   | Maximum replica count. |\n\n### `ScalingMetricSpec`\n\n`concurrency` and `requestRate` are mutually exclusive.\nSetting both produces undefined behavior.\nThis differs from [InterceptorRoute](../interceptorroute/), which allows both to be set simultaneously.\n\n| Field         | Type                                               | Required | Default | Description                                             |\n| ------------- | -------------------------------------------------- | -------- | ------- | ------------------------------------------------------- |\n| `concurrency` | [`*ConcurrencyMetricSpec`](#concurrencymetricspec) | No       |         | Scale based on concurrent requests.                     |\n| `requestRate` | [`*RateMetricSpec`](#ratemetricspec)               | No       |         | Scale based on average request rate over a time window. |\n\n### `ConcurrencyMetricSpec`\n\n| Field         | Type  | Required | Default | Description                                  |\n| ------------- | ----- | -------- | ------- | -------------------------------------------- |\n| `targetValue` | `int` | No       | `100`   | Target concurrent request count per replica. |\n\n### `RateMetricSpec`\n\n| Field         | Type       | Required | Default | Description                            |\n| ------------- | ---------- | -------- | ------- | -------------------------------------- |\n| `targetValue` | `int`      | No       | `100`   | Target request rate per replica.       |\n| `window`      | `Duration` | No       | `1m`    | Time window for rate calculation.      |\n| `granularity` | `Duration` | No       | `1s`    | Time granularity for rate calculation. |\n\n### `ColdStartTimeoutFailoverRef`\n\n| Field            | Type     | Required | Default | Description                                             |\n| ---------------- | -------- | -------- | ------- | ------------------------------------------------------- |\n| `service`        | `string` | Yes      |         | Name of the failover Service to route to.               |\n| `port`           | `int32`  | No       |         | Port number on the failover Service.                    |\n| `portName`       | `string` | No       |         | Named port on the failover Service.                     |\n| `timeoutSeconds` | `int32`  | No       | `30`    | Seconds to wait before routing to the failover service. |\n\n**Validation:** Exactly one of `port` or `portName` must be set.\n\n### `HTTPScaledObjectTimeoutsSpec`\n\n| Field            | Type       | Required | Default                               | Description                                                                                                       |\n| ---------------- | ---------- | -------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| `conditionWait`  | `Duration` | No       | Global `KEDA_CONDITION_WAIT_TIMEOUT`  | Time to wait for the backing workload to reach 1 or more replicas before connecting and sending the HTTP request. |\n| `responseHeader` | `Duration` | No       | Global `KEDA_RESPONSE_HEADER_TIMEOUT` | Time to wait for response headers after the HTTP request is sent to the backing application.                      |\n\n## `status`\n\n| Field            | Type                 | Description                                          |\n| ---------------- | -------------------- | ---------------------------------------------------- |\n| `targetWorkload` | `string`             | Resolved target workload reference.                  |\n| `targetService`  | `string`             | Resolved target service reference.                   |\n| `conditions`     | `[]metav1.Condition` | Conditions of the HTTPScaledObject. Keyed by `type`. |\n\n### Condition types\n\n| Type    | Description                                                           |\n| ------- | --------------------------------------------------------------------- |\n| `Ready` | Whether the HTTPScaledObject is fully reconciled and routing traffic. |\n"
  },
  {
    "path": "content/http-add-on/0.14/reference/interceptorroute.md",
    "content": "+++\ntitle = \"InterceptorRoute\"\ndescription = \"Field-by-field API reference for the InterceptorRoute custom resource\"\n+++\n\n|                 |                        |\n| --------------- | ---------------------- |\n| **API version** | `http.keda.sh/v1beta1` |\n| **Kind**        | `InterceptorRoute`     |\n| **Scope**       | Namespaced             |\n\n## Example\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\n  namespace: default\nspec:\n  target:\n    service: my-app-svc\n    port: 8080\n  rules:\n    - hosts:\n        - app.example.com\n      paths:\n        - value: /api\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n```\n\n## `spec`\n\n| Field           | Type                                                    | Required | Default | Description                                                        |\n| --------------- | ------------------------------------------------------- | -------- | ------- | ------------------------------------------------------------------ |\n| `target`        | [`TargetRef`](#targetref)                               | Yes      |         | Backend service to route traffic to.                               |\n| `rules`         | [`[]RoutingRule`](#routingrule)                         | No       |         | Routing rules that define how requests are matched to this target. |\n| `scalingMetric` | [`ScalingMetricSpec`](#scalingmetricspec)               | Yes      |         | Metric configuration for autoscaling.                              |\n| `coldStart`     | [`ColdStartSpec`](#coldstartspec)                       | No       |         | Cold start behavior when scaling from zero.                        |\n| `timeouts`      | [`InterceptorRouteTimeouts`](#interceptorroutetimeouts) | No       |         | Timeout configuration for request handling.                        |\n\nFor usage guidance, see [Configure Routing Rules](../../user-guide/configure-routing/) and [Configure Scaling Metrics](../../user-guide/configure-scaling/).\n\n### `TargetRef`\n\nIdentifies a Service to route traffic to.\nExactly one of `port` or `portName` must be set.\n\n| Field      | Type     | Required | Default | Description                                                                   |\n| ---------- | -------- | -------- | ------- | ----------------------------------------------------------------------------- |\n| `service`  | `string` | Yes      |         | Name of the Kubernetes Service. Minimum length: 1.                            |\n| `port`     | `int32`  | No       |         | Port number on the Service (1--65535). Mutually exclusive with `portName`.    |\n| `portName` | `string` | No       |         | Named port on the Service. Minimum length: 1. Mutually exclusive with `port`. |\n\n**Validation:** Exactly one of `port` or `portName` must be set.\nSetting both or neither produces a validation error.\n\n### `RoutingRule`\n\nDefines a set of matching criteria for routing requests.\nAll specified fields within a single rule use AND semantics (host AND path AND headers must match).\nMultiple rules use OR semantics (any rule can match).\n\n| Field     | Type                            | Required | Default | Description                                                                                                                                                                                                                                           |\n| --------- | ------------------------------- | -------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `hosts`   | `[]string`                      | No       |         | Hostnames to match. Wildcard patterns (e.g., `*.example.com`) are supported. A single `*` acts as a catch-all. Exact matches take priority over wildcards; more specific wildcards (e.g., `*.bar.example.com`) take priority over less specific ones. |\n| `paths`   | [`[]PathMatch`](#pathmatch)     | No       |         | Path prefixes to match. When multiple paths match, the longest prefix wins.                                                                                                                                                                           |\n| `headers` | [`[]HeaderMatch`](#headermatch) | No       |         | Headers that must all match the request (AND semantics).                                                                                                                                                                                              |\n\n### `PathMatch`\n\n| Field   | Type     | Required | Default | Description                                                                        |\n| ------- | -------- | -------- | ------- | ---------------------------------------------------------------------------------- |\n| `value` | `string` | Yes      |         | Path prefix to match against. The longest matching prefix wins. Minimum length: 1. |\n\n### `HeaderMatch`\n\n| Field   | Type      | Required | Default | Description                                                                                    |\n| ------- | --------- | -------- | ------- | ---------------------------------------------------------------------------------------------- |\n| `name`  | `string`  | Yes      |         | Name of the HTTP header. Minimum length: 1.                                                    |\n| `value` | `*string` | No       |         | Value to match against (exact match). If omitted, matches any value for the given header name. |\n\n### `ScalingMetricSpec`\n\nDefines what metric drives autoscaling.\nAt least one of `concurrency` or `requestRate` must be set.\nWhen both are set, both metrics are reported and KEDA scales based on whichever demands more replicas.\n\n| Field         | Type                                               | Required | Default | Description                              |\n| ------------- | -------------------------------------------------- | -------- | ------- | ---------------------------------------- |\n| `concurrency` | [`*ConcurrencyTargetSpec`](#concurrencytargetspec) | No       |         | Scale based on concurrent request count. |\n| `requestRate` | [`*RequestRateTargetSpec`](#requestratetargetspec) | No       |         | Scale based on request rate.             |\n\n**Validation:** At least one of `concurrency` or `requestRate` must be set.\n\n### `ConcurrencyTargetSpec`\n\n| Field         | Type    | Required | Default | Description                                              |\n| ------------- | ------- | -------- | ------- | -------------------------------------------------------- |\n| `targetValue` | `int32` | Yes      |         | Target concurrent request count per replica. Minimum: 1. |\n\n### `RequestRateTargetSpec`\n\n| Field         | Type       | Required | Default | Description                                                    |\n| ------------- | ---------- | -------- | ------- | -------------------------------------------------------------- |\n| `targetValue` | `int32`    | Yes      |         | Target request rate per replica. Minimum: 1.                   |\n| `window`      | `Duration` | No       | `1m`    | Sliding time window over which the request rate is calculated. |\n| `granularity` | `Duration` | No       | `1s`    | Bucket size for rate calculation within the window.            |\n\n### `ColdStartSpec`\n\nConfigures behavior while the target is not ready (scaling from zero).\n\n| Field      | Type                       | Required | Default | Description                                                                                     |\n| ---------- | -------------------------- | -------- | ------- | ----------------------------------------------------------------------------------------------- |\n| `fallback` | [`*TargetRef`](#targetref) | Yes      |         | Fallback service to route to when the target is scaling from zero and the wait timeout expires. |\n\n**Validation:** The `fallback` field must be set.\n\n### `InterceptorRouteTimeouts`\n\nConfigures per-route request handling timeouts.\nWhen a field is unset, the global interceptor timeout configuration (`KEDA_HTTP_*_TIMEOUT` environment variables) is used.\n\n| Field            | Type        | Required | Default                                    | Description                                                                                                                                                                                                                                                              |\n| ---------------- | ----------- | -------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `readiness`      | `*Duration` | No       | Global `KEDA_HTTP_READINESS_TIMEOUT`       | Time to wait for the backend to become ready (e.g., scale from zero). Set to `0s` to disable the dedicated readiness deadline so the full request budget is available for cold starts. When a fallback service is configured and this is `0s`, a 30s default is applied. |\n| `request`        | `*Duration` | No       | Global `KEDA_HTTP_REQUEST_TIMEOUT`         | Total time allowed for the entire request lifecycle. Set to `0s` to disable the request deadline.                                                                                                                                                                        |\n| `responseHeader` | `*Duration` | No       | Global `KEDA_HTTP_RESPONSE_HEADER_TIMEOUT` | Maximum time to wait for response headers from the backend after the request has been sent. Does not include cold-start wait time. Set to `0s` to disable the response header deadline.                                                                                  |\n\n## `status`\n\n| Field        | Type                 | Description                                          |\n| ------------ | -------------------- | ---------------------------------------------------- |\n| `conditions` | `[]metav1.Condition` | Conditions of the InterceptorRoute. Keyed by `type`. |\n\n### Condition types\n\n| Type    | Description                                                           |\n| ------- | --------------------------------------------------------------------- |\n| `Ready` | Whether the InterceptorRoute is fully reconciled and routing traffic. |\n"
  },
  {
    "path": "content/http-add-on/0.14/reference/metrics.md",
    "content": "+++\ntitle = \"Metrics\"\ndescription = \"Reference for all Prometheus metrics exposed by the HTTP Add-on\"\n+++\n\nThe interceptor exposes metrics via OpenTelemetry, with a Prometheus-compatible endpoint enabled by default.\n\n## Endpoint configuration\n\n| Setting | Default    | Description                                    |\n| ------- | ---------- | ---------------------------------------------- |\n| Port    | `2223`     | Configurable via `OTEL_PROM_EXPORTER_PORT`.    |\n| Path    | `/metrics` | Standard Prometheus scrape path.               |\n| Enabled | `true`     | Configurable via `OTEL_PROM_EXPORTER_ENABLED`. |\n\nThe interceptor also supports OTLP metric export.\nSee [Environment Variables](../environment-variables/#metrics) for configuration.\n\n## Metrics\n\n### Request count\n\n|                          |                                                    |\n| ------------------------ | -------------------------------------------------- |\n| **Prometheus name**      | `interceptor_request_count_total`                  |\n| **OTel instrument name** | `interceptor.request.count`                        |\n| **Type**                 | Counter                                            |\n| **Description**          | Total requests processed by the interceptor proxy. |\n\n**Labels:**\n\n| Label             | Description                                                                                                               |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------- |\n| `code`            | HTTP response status code (integer).                                                                                      |\n| `method`          | HTTP request method. Non-standard methods are normalized to `_OTHER` (see [Method normalization](#method-normalization)). |\n| `route_name`      | Name of the matched InterceptorRoute or HTTPScaledObject.                                                                 |\n| `route_namespace` | Namespace of the matched route resource.                                                                                  |\n\n### Request concurrency\n\n|                          |                                                        |\n| ------------------------ | ------------------------------------------------------ |\n| **Prometheus name**      | `interceptor_request_concurrency`                      |\n| **OTel instrument name** | `interceptor.request.concurrency`                      |\n| **Type**                 | UpDownCounter (gauge)                                  |\n| **Description**          | Requests currently in-flight at the interceptor proxy. |\n\n**Labels:**\n\n| Label             | Description                                               |\n| ----------------- | --------------------------------------------------------- |\n| `route_name`      | Name of the matched InterceptorRoute or HTTPScaledObject. |\n| `route_namespace` | Namespace of the matched route resource.                  |\n\n### Request duration\n\n|                          |                                                 |\n| ------------------------ | ----------------------------------------------- |\n| **Prometheus name**      | `interceptor_request_duration_seconds`          |\n| **OTel instrument name** | `interceptor.request.duration`                  |\n| **Type**                 | Histogram                                       |\n| **Unit**                 | Seconds                                         |\n| **Description**          | Time from request received to response written. |\n\n**Bucket boundaries:** `0.005`, `0.01`, `0.025`, `0.05`, `0.075`, `0.1`, `0.25`, `0.5`, `0.75`, `1`, `2.5`, `5`, `7.5`, `10` (following the [OTel HTTP semantic conventions](https://opentelemetry.io/docs/specs/semconv/http/http-metrics/)).\n\n**Labels:**\n\n| Label             | Description                                                                                                               |\n| ----------------- | ------------------------------------------------------------------------------------------------------------------------- |\n| `code`            | HTTP response status code (integer).                                                                                      |\n| `method`          | HTTP request method. Non-standard methods are normalized to `_OTHER` (see [Method normalization](#method-normalization)). |\n| `route_name`      | Name of the matched InterceptorRoute or HTTPScaledObject.                                                                 |\n| `route_namespace` | Namespace of the matched route resource.                                                                                  |\n\n## Method normalization\n\nThe `method` label accepts the following standard HTTP methods without modification:\n\n`CONNECT`, `DELETE`, `GET`, `HEAD`, `OPTIONS`, `PATCH`, `POST`, `PUT`, `TRACE`\n\nAll other method values are replaced with `_OTHER` to prevent unbounded label cardinality.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/_index.md",
    "content": "+++\ntitle = \"User Guide\"\ndescription = \"Autoscaling, routing, and timeout configuration for HTTP applications\"\nweight = 300\n+++\n\nGuides for application developers using the HTTP Add-on to autoscale their services.\n\n- **[Autoscale an App](autoscale-an-app/)** — Create a ScaledObject and InterceptorRoute for your service.\n- **[Configure Cold-Start Behavior](configure-cold-start/)** — Fallback services and cold-start response headers.\n- **[Configure Ingress](configure-ingress/)** — Point your Gateway API or Ingress at the interceptor proxy.\n- **[Configure Routing Rules](configure-routing/)** — Host, path, and header matching.\n- **[Configure Scaling Metrics](configure-scaling/)** — Choose between concurrency and request rate metrics.\n- **[Configure Timeouts](configure-timeouts/)** — Per-route timeout overrides.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/autoscale-an-app.md",
    "content": "+++\ntitle = \"Autoscale an App\"\ndescription = \"ScaledObject and InterceptorRoute configuration for autoscaling an HTTP service\"\n+++\n\nThis guide walks you through the two resources needed to autoscale an existing HTTP service with the KEDA HTTP Add-on: an `InterceptorRoute` and a KEDA `ScaledObject`.\n\n## Prerequisites\n\n- The HTTP Add-on is [installed](../operations/installation/) in your cluster.\n- You have an existing Deployment (or other workload) and a Service for your HTTP application.\n\n## Step 1: Create an InterceptorRoute\n\nThe `InterceptorRoute` tells the interceptor how to route requests to your service and what scaling metrics to report.\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: <your-app>\n  namespace: <your-namespace>\nspec:\n  target:\n    service: <your-service>\n    port: 80\n  rules:\n    - hosts:\n        - <your-hostname>\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n```\n\nKey fields:\n\n- **`target.service`** / **`target.port`** — The Kubernetes Service and port to route traffic to.\n- **`rules[].hosts`** — Hostnames to match against the HTTP `Host` header. This must match what callers send (see [Step 4](#step-4-route-traffic-through-the-interceptor)):\n  - External traffic: your public hostname (e.g., `app.example.com`).\n  - In-cluster traffic: the service name callers use (e.g., `<your-service>-proxy`).\n  - Wildcards like `*.example.com` are supported.\n- **`scalingMetric.concurrency.targetValue`** — Target concurrent requests per replica. KEDA scales replicas so each handles approximately this many concurrent requests.\n\n## Step 2: Create a ScaledObject\n\nThe `ScaledObject` tells KEDA how to scale your workload.\nIt references the HTTP Add-on's scaler using the `external-push` trigger type.\n\n> **Create the ScaledObject after the InterceptorRoute.** When KEDA reconciles a ScaledObject with an `external-push` trigger, it calls the scaler's `GetMetricSpec` endpoint. If the InterceptorRoute does not exist yet, the scaler returns an empty metric spec and KEDA falls back to a default CPU metric in the HPA, which prevents scale-up from working.\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: <your-app>\n  namespace: <your-namespace>\nspec:\n  scaleTargetRef:\n    name: <your-deployment>\n  minReplicaCount: 0\n  maxReplicaCount: 10\n  cooldownPeriod: 300\n  triggers:\n    - type: external-push\n      metadata:\n        scalerAddress: keda-add-ons-http-external-scaler.keda:9090\n        interceptorRoute: <your-app>\n```\n\nKey fields:\n\n- **`scaleTargetRef.name`** — The name of the Deployment (or StatefulSet, etc.) to scale.\n- **`minReplicaCount`** — Set to `0` for scale-to-zero, or higher to keep a minimum number of replicas running.\n- **`maxReplicaCount`** — Upper bound for the number of replicas.\n- **`cooldownPeriod`** — Seconds to wait before scaling down after traffic stops (default: `300`).\n- **`scalerAddress`** — The HTTP Add-on scaler gRPC service address. If KEDA is installed in a namespace other than `keda`, adjust accordingly.\n- **`interceptorRoute`** — Must match the `metadata.name` of the InterceptorRoute created in the previous step.\n\n## Step 3: Verify\n\n1. Check that the ScaledObject is ready:\n\n   ```shell\n   kubectl get scaledobject <your-app> -n <your-namespace>\n   ```\n\n   The `READY` column should show `True`.\n\n2. Check that the InterceptorRoute is ready:\n\n   ```shell\n   kubectl get interceptorroute <your-app> -n <your-namespace>\n   ```\n\n   The `READY` column should show `True`.\n\n## Step 4: Route Traffic Through the Interceptor\n\nFor autoscaling to work, traffic must flow through the interceptor instead of directly to your application.\nThis applies to both in-cluster and external traffic.\n\n### In-cluster traffic\n\nIf other services in your cluster call your application directly, redirect them to the interceptor proxy service (`keda-add-ons-http-interceptor-proxy` in the `keda` namespace).\n\nCreate an `ExternalName` service in your application's namespace so callers can reach the interceptor:\n\n```yaml\napiVersion: v1\nkind: Service\nmetadata:\n  name: <your-service>-proxy\n  namespace: <your-namespace>\nspec:\n  type: ExternalName\n  externalName: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local\n  ports:\n    - port: 8080\n```\n\nUpdate callers to use `<your-service>-proxy` instead of `<your-service>`.\nThe `hosts` in your InterceptorRoute must include the hostname that callers use in the `Host` header — typically the service name (e.g., `<your-service>-proxy` or `<your-service>-proxy.<your-namespace>.svc.cluster.local`).\n\n### External traffic\n\nFor traffic entering the cluster from outside, configure your ingress or gateway to point at the interceptor proxy service instead of your application.\nSee [Configure Ingress](../configure-ingress/) for Gateway API, Ingress, and Istio examples.\n\n## What's Next\n\n- **[Configure Routing Rules](../configure-routing/)** — Add path prefixes, wildcards, or header matching.\n- **[Configure Scaling Metrics](../configure-scaling/)** — Switch to request rate or use both concurrency and rate metrics.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/configure-cold-start.md",
    "content": "+++\ntitle = \"Configure Cold-Start Behavior\"\ndescription = \"Fallback services and response headers for cold-start scenarios\"\n+++\n\nWhen a request arrives for a backend that has been scaled to zero, the interceptor holds the request until the backend becomes ready.\nYou can configure a fallback service and a readiness timeout to control what happens if the backend takes too long to start.\n\n## Cold-start fallback\n\nWhen the readiness timeout expires during a cold start, the interceptor returns an error by default.\nTo serve requests from a fallback service instead, configure the `coldStart.fallback` field:\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n  coldStart:\n    fallback:\n      service: <your-fallback-service>\n      port: <your-fallback-port>\n  timeouts:\n    readiness: 5s\n```\n\nWhen a fallback is configured but the readiness timeout is `0s` (disabled), a 30-second default readiness timeout is applied automatically.\nThis prevents the fallback from never being triggered.\n\n## Cold-start response header\n\nThe interceptor adds an `X-KEDA-HTTP-Cold-Start` response header to indicate whether a cold start occurred:\n\n- `X-KEDA-HTTP-Cold-Start: true` — the request triggered a scale-from-zero.\n- `X-KEDA-HTTP-Cold-Start: false` — the backend was already running.\n\nThis header is enabled by default.\nTo disable it, see [Configure the Interceptor](../operations/configure-interceptor/#cold-start-response-header).\n\n## What's Next\n\n- [How Scaling Works](../concepts/scaling/) — cold-start mechanics and scale-from-zero behavior.\n- [Configure Timeouts](../configure-timeouts/) — per-route timeout overrides.\n- [InterceptorRoute Reference](../reference/interceptorroute/) — field details for `coldStart`.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/configure-ingress.md",
    "content": "+++\ntitle = \"Configure Ingress\"\ndescription = \"Gateway API and Ingress configuration for interceptor proxy traffic\"\n+++\n\nFor the HTTP Add-on to intercept and scale your HTTP traffic, external requests must be routed to the **interceptor proxy service** (`keda-add-ons-http-interceptor-proxy`) instead of directly to your application.\nThe interceptor then forwards requests to your application based on the InterceptorRoute configuration.\n\nThe HTTP Add-on is ingress-agnostic — it works with any ingress controller or Gateway API implementation.\n\n## Using Gateway API\n\n[Gateway API](https://gateway-api.sigs.k8s.io/) is the recommended approach for new Kubernetes clusters.\n\n### Step 1: Create an HTTPRoute\n\nCreate an HTTPRoute that sends traffic to the interceptor proxy service:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: <your-app>\n  namespace: <your-namespace>\nspec:\n  parentRefs:\n    - name: <your-gateway>\n      namespace: <gateway-namespace>\n  hostnames:\n    - <your-hostname>\n  rules:\n    - backendRefs:\n        - name: keda-add-ons-http-interceptor-proxy\n          namespace: keda\n          port: 8080\n```\n\nThe `hostnames` in the HTTPRoute should match the `hosts` in your InterceptorRoute so the interceptor can route the request correctly.\n\n### Step 2: Create a ReferenceGrant\n\nCross-namespace backend references require a `ReferenceGrant` in the `keda` namespace.\nThis grants the HTTPRoute's namespace permission to reference the interceptor service:\n\n```yaml\napiVersion: gateway.networking.k8s.io/v1beta1\nkind: ReferenceGrant\nmetadata:\n  name: allow-httproute-to-interceptor\n  namespace: keda\nspec:\n  from:\n    - group: gateway.networking.k8s.io\n      kind: HTTPRoute\n      namespace: <your-namespace>\n  to:\n    - group: \"\"\n      kind: Service\n      name: keda-add-ons-http-interceptor-proxy\n```\n\nIf your HTTPRoute is in the same namespace as the interceptor (e.g., `keda`), you do not need a ReferenceGrant.\n\n## Using Kubernetes Ingress\n\nCreate an Ingress resource that routes traffic to the interceptor proxy service:\n\n```yaml\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n  name: <your-app>\n  namespace: keda\nspec:\n  rules:\n    - host: <your-hostname>\n      http:\n        paths:\n          - path: /\n            pathType: Prefix\n            backend:\n              service:\n                name: keda-add-ons-http-interceptor-proxy\n                port:\n                  number: 8080\n```\n\nThe Ingress resource should be in the same namespace as the interceptor service (default: `keda`).\nIf your Ingress must live in a different namespace, create an `ExternalName` Service to reference the interceptor across namespaces.\n\n## Using Istio\n\nAdd the interceptor proxy service as a destination in your Istio `VirtualService`:\n\n```yaml\napiVersion: networking.istio.io/v1\nkind: VirtualService\nmetadata:\n  name: <your-app>\n  namespace: <your-namespace>\nspec:\n  hosts:\n    - <your-hostname>\n  gateways:\n    - <your-gateway>\n  http:\n    - route:\n        - destination:\n            host: keda-add-ons-http-interceptor-proxy.keda.svc.cluster.local\n            port:\n              number: 8080\n```\n\nThe `host` field uses the fully qualified service name because the VirtualService and the interceptor are in different namespaces.\n\n> **Note:** Creating the ReferenceGrant shown in the Gateway API section is not required for Istio — Istio's VirtualService uses DNS-based service discovery, not Kubernetes cross-namespace backend references.\n\n## Verifying Traffic Flow\n\n1. Confirm the interceptor proxy service exists:\n\n   ```shell\n   kubectl get svc keda-add-ons-http-interceptor-proxy -n keda\n   ```\n\n2. Find your ingress endpoint.\n   For Gateway API, check the Gateway's address:\n\n   ```shell\n   kubectl get gateway <your-gateway> -n <gateway-namespace> -o jsonpath='{.status.addresses[0].value}'\n   ```\n\n   For Ingress, check the Ingress address:\n\n   ```shell\n   kubectl get ingress <your-app> -n keda -o jsonpath='{.status.loadBalancer.ingress[0].ip}'\n   ```\n\n3. Send a test request:\n\n   ```shell\n   curl http://<ingress-address>/\n   ```\n\n4. Verify the request reached your application by checking your application logs or response.\n\n## What's Next\n\n- [Architecture](../concepts/architecture/) — Understand how the interceptor fits into the request flow.\n- [Autoscale an App](../autoscale-an-app/) — Create the ScaledObject and InterceptorRoute resources.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/configure-routing.md",
    "content": "+++\ntitle = \"Configure Routing Rules\"\ndescription = \"Host, path, and header matching rules on an InterceptorRoute\"\n+++\n\nAn `InterceptorRoute` uses **rules** to match incoming requests to a target service.\nEach rule can match on hostnames, path prefixes, and headers.\nA request that matches any rule in the list is routed to the target.\n\n## Single host\n\nRoute all traffic for a single hostname:\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n  rules:\n    - hosts:\n        - api.example.com\n```\n\n## Multiple hosts\n\nRoute traffic for several hostnames to the same target:\n\n```yaml\nspec:\n  rules:\n    - hosts:\n        - api.example.com\n        - api.staging.example.com\n```\n\n## Wildcard hosts\n\nUse a wildcard prefix to match any subdomain.\n`*.example.com` matches `foo.example.com`, `bar.baz.example.com`, and so on.\n\n```yaml\nspec:\n  rules:\n    - hosts:\n        - \"*.example.com\"\n```\n\nA single `*` acts as a catch-all that matches every hostname.\n\nWhen multiple wildcard patterns match a request, more specific wildcards take priority.\nFor example, `*.bar.example.com` wins over `*.example.com`.\nExact matches always take priority over wildcards.\n\n## Path prefixes\n\nAdd path prefixes to narrow a rule to specific URL paths:\n\n```yaml\nspec:\n  rules:\n    - hosts:\n        - api.example.com\n      paths:\n        - value: /api/v1\n        - value: /api/v2\n```\n\nWhen multiple path prefixes match, the longest prefix wins.\nA request to `/api/v1/users` matches `/api/v1` over `/api`.\n\n## Header matching\n\nHeaders use AND semantics — all specified headers must match for the rule to apply.\n\n### Match by exact value\n\n```yaml\nspec:\n  rules:\n    - hosts:\n        - api.example.com\n      headers:\n        - name: X-Route\n          value: canary\n```\n\n### Match by presence\n\nOmit the `value` field to match any request that includes the header, regardless of its value:\n\n```yaml\nspec:\n  rules:\n    - hosts:\n        - api.example.com\n      headers:\n        - name: X-Route\n```\n\n## Multiple rules\n\nAn `InterceptorRoute` can have multiple rules.\nA request matching **any** rule is routed to the same target:\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n  rules:\n    - hosts:\n        - api.example.com\n      paths:\n        - value: /api\n    - hosts:\n        - admin.example.com\n```\n\nIn this example, requests to `api.example.com/api/*` and `admin.example.com/*` both route to the same service.\n\n## Routing priority\n\nWhen rules from different `InterceptorRoute` resources overlap, the interceptor evaluates them in priority order:\n\n1. Exact host matches beat wildcards.\n2. More specific wildcards beat less specific ones.\n3. Longer path prefixes beat shorter ones.\n4. Header-matching rules beat rules without headers.\n\nFor a detailed explanation, see [How Routing Works](../concepts/routing/).\n\n## What's Next\n\n- [InterceptorRoute Reference](../reference/interceptorroute/) — complete field definitions for rules, hosts, paths, and headers.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/configure-scaling.md",
    "content": "+++\ntitle = \"Configure Scaling Metrics\"\ndescription = \"Autoscaling metric configuration on an InterceptorRoute\"\n+++\n\nThe `scalingMetric` field on an `InterceptorRoute` determines what metric drives autoscaling.\nYou can scale based on concurrent request count, request rate, or both.\nAt least one metric must be set.\n\n## Concurrency metric\n\nScale based on the number of in-flight requests per replica:\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n```\n\nThe add-on targets `targetValue` concurrent requests per replica.\nWhen the total concurrent requests across all replicas exceeds `replicas * targetValue`, KEDA scales up.\n\n| Field         | Required | Description                                  |\n| ------------- | -------- | -------------------------------------------- |\n| `targetValue` | Yes      | Target concurrent request count per replica. |\n\n## Request rate metric\n\nScale based on requests per second, averaged over a sliding window:\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    requestRate:\n      targetValue: 100\n      window: 1m\n      granularity: 1s\n```\n\n| Field         | Required | Description                                                                                                                   |\n| ------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------- |\n| `targetValue` | Yes      | Target requests per second per replica.                                                                                       |\n| `window`      | `1m`     | Sliding time window over which the average request rate is calculated.                                                        |\n| `granularity` | `1s`     | Bucket size within the window. Smaller granularity gives more responsive scaling at the cost of higher sensitivity to bursts. |\n\n## Using both metrics\n\nAn `InterceptorRoute` can set both `concurrency` and `requestRate`.\nKEDA scales to whichever metric demands more replicas.\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    concurrency:\n      targetValue: 50\n    requestRate:\n      targetValue: 200\n```\n\nThis is useful when you want to handle both sustained throughput (rate) and bursty traffic (concurrency).\n\n## Scaling boundaries and cooldown\n\nMinimum and maximum replica counts and cooldown are set on the KEDA `ScaledObject`, not the `InterceptorRoute`:\n\n```yaml\napiVersion: keda.sh/v1alpha1\nkind: ScaledObject\nmetadata:\n  name: my-app\nspec:\n  scaleTargetRef:\n    name: <your-deployment>\n  minReplicaCount: 0 # 0 enables scale-to-zero\n  maxReplicaCount: 10\n  cooldownPeriod: 300 # seconds before scaling to zero after traffic stops\n```\n\nSetting `minReplicaCount: 0` enables scale-to-zero.\nThe `cooldownPeriod` controls how long KEDA waits after the last request before scaling the workload down to zero replicas.\n\n## What's Next\n\n- [How Scaling Works](../concepts/scaling/) — the full scaling mechanics, including scale-to-zero and cold starts.\n- [InterceptorRoute Reference](../reference/interceptorroute/) — field details for `scalingMetric`, `concurrency`, and `requestRate`.\n"
  },
  {
    "path": "content/http-add-on/0.14/user-guide/configure-timeouts.md",
    "content": "+++\ntitle = \"Configure Timeouts\"\ndescription = \"Per-route timeout configuration\"\n+++\n\nYou can override the cluster-wide timeout defaults on individual routes using the `InterceptorRoute` spec.\nFor global timeout defaults, see [Configure the Interceptor](../operations/configure-interceptor/#timeouts).\n\n## Timeout types\n\n| Timeout             | Description                                                                                                                          |\n| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |\n| **Request**         | Total deadline for the entire request lifecycle, from arrival to response completion.                                                |\n| **Response header** | Maximum time to wait for the backend to send response headers after the request is forwarded. Does not include cold-start wait time. |\n| **Readiness**       | Maximum time to wait for the backend to become ready during a cold start (scale from zero).                                          |\n\n## Per-route overrides\n\nOverride timeouts for a specific route via the `InterceptorRoute` spec:\n\n```yaml\napiVersion: http.keda.sh/v1beta1\nkind: InterceptorRoute\nmetadata:\n  name: my-app\nspec:\n  target:\n    service: <your-service>\n    port: <your-port>\n  scalingMetric:\n    concurrency:\n      targetValue: 100\n  timeouts:\n    request: 60s\n    responseHeader: 30s\n    readiness: 10s\n```\n\n### Override semantics\n\n- When a timeout field is **omitted** (not set) in the `InterceptorRoute`, the global default applies.\n- When a timeout field is set to **`0s`**, that timeout is disabled for this route.\n- When a timeout field is set to a **positive value**, it overrides the global default for this route.\n\n## Timeout errors\n\nWhen a timeout is exceeded, the interceptor returns one of these HTTP status codes:\n\n| Condition                                        | HTTP status           |\n| ------------------------------------------------ | --------------------- |\n| Request timeout exceeded                         | `504 Gateway Timeout` |\n| Response header timeout exceeded                 | `504 Gateway Timeout` |\n| Readiness timeout exceeded (no fallback)         | `504 Gateway Timeout` |\n| Backend error (non-timeout failure, no fallback) | `502 Bad Gateway`     |\n\n## What's Next\n\n- [Configure Cold-Start Behavior](../configure-cold-start/) — fallback services and cold-start response headers.\n- [Configure the Interceptor](../operations/configure-interceptor/#timeouts) — global timeout defaults.\n- [InterceptorRoute Reference](../reference/interceptorroute/) — field details for `timeouts`.\n"
  },
  {
    "path": "content/http-add-on/_index.md",
    "content": "---\nbuild:\n  render: false\n---\n"
  },
  {
    "path": "content/resources.md",
    "content": "+++\ntitle = \"Resources\"\ndescription = \"Materials for learning more about KEDA\"\n+++\n\n## Learning Courses\n\n- [\"Scale container applications in Azure Kubernetes Services using KEDA\"](https://docs.microsoft.com/en-us/learn/modules/aks-app-scale-keda/) on Microsoft Learn\n- [\"Kubernetes Autoscaling\"](https://learn.kodekloud.com/courses/kubernetes-autoscaling) on KodeKloud\n- [\"Mastering Kubernetes Event-driven Autoscaling with KEDA (LFS257)\"](https://training.linuxfoundation.org/training/mastering-kubernetes-event-driven-autoscaling-with-keda-lfs257/) on Linux Foundation\n\n## Videos\n\n### Application Autoscaling Made Easy with Kubernetes Event-driven Autoscaling (KEDA)\n\n[KubeCon Europe 2021](https://kccnceu2021.sched.com/event/iE5l/application-autoscaling-made-easy-with-kubernetes-event-driven-autoscaling-tom-kerkhove-codit) presented by [Tom Kerkhove](https://twitter.com/TomKerkhove).\n\n{{< youtube \"H5eZEq_wqSE\" >}}\n\n### KEDA: Event-driven and Serverless Containers in Kubernetes\n\n[KubeCon North America 2019](https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019) presentation by [Jeff Hollan](https://twitter.com/jeffhollan).\n\n{{< youtube \"ZK2SS_GXF-g\" >}}\n"
  },
  {
    "path": "content/support.md",
    "content": "+++\ntitle = \"Support\"\ndescription = \"Support for deploying and using KEDA\"\n+++\n\n## Open-Source (OSS) support\nKEDA is an open-source project under the CNCF and is community-supported on a best-effort basis. Use GitHub to track bugs and feature requests.\n\nWant to contribute a feature or fix? We are more than happy to review requests and contributions, but recommend going through our [contribution guide](https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md).\n\nLearn more in our [support policy](https://github.com/kedacore/governance/blob/main/SUPPORT.md).\n\nKubernetes compatibility and tested versions are described in the [documentation](https://keda.sh/docs/latest/operate/cluster/#kubernetes-compatibility).\n\n## Commercial support\n\nPlease refer to the [Enterprise page](enterprise) for details on commercially supported solutions based on KEDA.\n"
  },
  {
    "path": "content/troubleshooting/2.17/api-server-throttling.md",
    "content": "+++\ntitle = \"Troubleshooting API Server Throttling\"\ndescription = \"Learn how to troubleshoot and resolve KEDA API server throttling issues\"\nweight = 500\n+++\n\n# Troubleshooting KEDA API Server Throttling\n\nIf you are experiencing messages like \"Waited for ... due to client-side throttling\" in your KEDA operator logs, it might indicate that the KEDA operator is being throttled by the Kubernetes API server. This can happen in environments with a large number of `ScaledObject` resources.\n\nKEDA provides several command-line flags to control its interaction with the Kubernetes API server. Adjusting these flags can help alleviate client-side throttling.\n\n## Key Configuration Parameters\n\nThe following flags are relevant for tuning KEDA's API server interaction:\n\n*   `--kube-api-qps` (Default: `20.0`): This flag sets the maximum queries per second (QPS) that the KEDA operator can make to the Kubernetes API server.\n*   `--kube-api-burst` (Default: `30`): This flag sets the maximum burst of requests that the KEDA operator can make to the Kubernetes API server.\n\nThe following env variable is relevant for tuning KEDA's API server interaction:\n\n*   `KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES` (Default: `5`): This environment variable determines the maximum number of `ScaledObject` resources that the KEDA operator will reconcile concurrently.\n\n## Recommendation for Adjusting Flags\n\nIn environments with a large number of `ScaledObject` resources (e.g., 400 or more), the default values for these parameters might be too low.\n\nIt is recommended to experiment with increasing the values of these parameters:\n\n*   **`--kube-api-qps` and `--kube-api-burst`**: Increasing these values allows the KEDA operator to make more requests to the API server per unit of time.\n    *   Consider starting by doubling the default values (e.g., set `--kube-api-qps=40` and `--kube-api-burst=60`).\n    *   Monitor the impact on both KEDA's performance and the API server's load.\n*   **`KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES`**: Increasing this value allows KEDA to process more `ScaledObject` resources in parallel. However, this will also increase the overall load on the API server.\n    *   Consider a moderate increase (e.g., to `10`).\n    *   Observe the performance and API server load.\n\n## Important Considerations\n\n*   **API Server Load:** Increasing these parameters will inevitably increase the load on the Kubernetes API server. It is crucial to monitor the API server's performance (CPU, memory, request latency) after making these changes to ensure it is not being overwhelmed.\n*   **Gradual Adjustments:** Make adjustments to these parameters gradually. Monitor the system's behavior closely after each change. This iterative approach will help in finding the optimal values for your specific environment.\n*   **Throttling vs. Server Overload:** While these adjustments can help with client-side throttling, if the API server itself is overloaded, these changes might exacerbate the problem. Ensure your Kubernetes API server has sufficient resources (CPU, memory) to handle the increased load.\n\n## How to Apply Changes\n\nThese flags are typically set when deploying the KEDA operator. You will need to update the KEDA operator's deployment manifest (e.g., its `Deployment` YAML) to include these flags in the `args` section of the operator container.\n\n**Example (partial Deployment YAML):**\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  namespace: keda # Or your KEDA installation namespace\nspec:\n  template:\n    spec:\n      containers:\n      - name: keda-operator # Or keda-metrics-apiserver, depending on which component is throttled\n        args:\n        - \"--kube-api-qps=40\"\n        - \"--kube-api-burst=60\"\n        env:\n        - name: KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES\n          value: \"10\"\n        # ... other existing arguments for the KEDA operator\n```\n\n## Status Update Optimization\n\nAs of recent versions of KEDA, the operator includes built-in optimizations to reduce unnecessary ScaledObject status updates. The operator now:\n\n- **Compares condition states**: Before updating status, KEDA compares the new conditions (Type, Status, Reason, and Message) with existing ones\n- **Skips redundant updates**: Status updates are only performed when conditions have actually changed\n- **Handles edge cases**: Properly distinguishes between empty condition sets and initialized conditions with 'Unknown' status\n\nThis optimization is particularly beneficial in environments with many ScaledObjects, as it can significantly reduce the number of API calls made by the KEDA operator, helping to prevent API server throttling issues described above.\n\nFor the most up-to-date information about this optimization, refer to the [KEDA CHANGELOG](https://github.com/kedacore/keda/blob/main/CHANGELOG.md).\n\n## Expected Impact\n\nWith proper configuration and built-in optimizations, users typically experience:\n\n- **Reduced throttling messages**: Fewer \"client-side throttling\" warnings in KEDA operator logs\n- **Lower API server load**: Decreased request volume from KEDA operations to the Kubernetes API server\n- **Improved performance**: Better responsiveness in environments with 100+ ScaledObjects\n- **More stable scaling**: Consistent autoscaling behavior without throttling-related delays\n\n## Additional Troubleshooting\n\nBy carefully tuning these parameters and leveraging KEDA's built-in optimizations, you should be able to reduce or eliminate the client-side throttling experienced by the KEDA operator. If throttling persists even after these adjustments, consider:\n\n- Further investigation into the API server's capacity and resource allocation\n- Reviewing your ScaledObject configurations for potential optimizations\n- Consulting the KEDA community for environment-specific guidance\n\nIf issues continue, potential code-level optimizations within KEDA might be necessary, and feedback to the KEDA project maintainers would be valuable.\n"
  },
  {
    "path": "content/troubleshooting/2.18/api-server-throttling.md",
    "content": "+++\ntitle = \"Troubleshooting API Server Throttling\"\ndescription = \"Learn how to troubleshoot and resolve KEDA API server throttling issues\"\nweight = 500\n+++\n\n# Troubleshooting KEDA API Server Throttling\n\nIf you are experiencing messages like \"Waited for ... due to client-side throttling\" in your KEDA operator logs, it might indicate that the KEDA operator is being throttled by the Kubernetes API server. This can happen in environments with a large number of `ScaledObject` resources.\n\nKEDA provides several command-line flags to control its interaction with the Kubernetes API server. Adjusting these flags can help alleviate client-side throttling.\n\n## Key Configuration Parameters\n\nThe following flags are relevant for tuning KEDA's API server interaction:\n\n*   `--kube-api-qps` (Default: `20.0`): This flag sets the maximum queries per second (QPS) that the KEDA operator can make to the Kubernetes API server.\n*   `--kube-api-burst` (Default: `30`): This flag sets the maximum burst of requests that the KEDA operator can make to the Kubernetes API server.\n\nThe following env variable is relevant for tuning KEDA's API server interaction:\n\n*   `KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES` (Default: `5`): This environment variable determines the maximum number of `ScaledObject` resources that the KEDA operator will reconcile concurrently.\n\n## Recommendation for Adjusting Flags\n\nIn environments with a large number of `ScaledObject` resources (e.g., 400 or more), the default values for these parameters might be too low.\n\nIt is recommended to experiment with increasing the values of these parameters:\n\n*   **`--kube-api-qps` and `--kube-api-burst`**: Increasing these values allows the KEDA operator to make more requests to the API server per unit of time.\n    *   Consider starting by doubling the default values (e.g., set `--kube-api-qps=40` and `--kube-api-burst=60`).\n    *   Monitor the impact on both KEDA's performance and the API server's load.\n*   **`KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES`**: Increasing this value allows KEDA to process more `ScaledObject` resources in parallel. However, this will also increase the overall load on the API server.\n    *   Consider a moderate increase (e.g., to `10`).\n    *   Observe the performance and API server load.\n\n## Important Considerations\n\n*   **API Server Load:** Increasing these parameters will inevitably increase the load on the Kubernetes API server. It is crucial to monitor the API server's performance (CPU, memory, request latency) after making these changes to ensure it is not being overwhelmed.\n*   **Gradual Adjustments:** Make adjustments to these parameters gradually. Monitor the system's behavior closely after each change. This iterative approach will help in finding the optimal values for your specific environment.\n*   **Throttling vs. Server Overload:** While these adjustments can help with client-side throttling, if the API server itself is overloaded, these changes might exacerbate the problem. Ensure your Kubernetes API server has sufficient resources (CPU, memory) to handle the increased load.\n\n## How to Apply Changes\n\nThese flags are typically set when deploying the KEDA operator. You will need to update the KEDA operator's deployment manifest (e.g., its `Deployment` YAML) to include these flags in the `args` section of the operator container.\n\n**Example (partial Deployment YAML):**\n\n```yaml\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: keda-operator\n  namespace: keda # Or your KEDA installation namespace\nspec:\n  template:\n    spec:\n      containers:\n      - name: keda-operator # Or keda-metrics-apiserver, depending on which component is throttled\n        args:\n        - \"--kube-api-qps=40\"\n        - \"--kube-api-burst=60\"\n        env:\n        - name: KEDA_SCALEDOBJECT_CTRL_MAX_RECONCILES\n          value: \"10\"\n        # ... other existing arguments for the KEDA operator\n```\n\n## Status Update Optimization\n\nAs of recent versions of KEDA, the operator includes built-in optimizations to reduce unnecessary ScaledObject status updates. The operator now:\n\n- **Compares condition states**: Before updating status, KEDA compares the new conditions (Type, Status, Reason, and Message) with existing ones\n- **Skips redundant updates**: Status updates are only performed when conditions have actually changed\n- **Handles edge cases**: Properly distinguishes between empty condition sets and initialized conditions with 'Unknown' status\n\nThis optimization is particularly beneficial in environments with many ScaledObjects, as it can significantly reduce the number of API calls made by the KEDA operator, helping to prevent API server throttling issues described above.\n\nFor the most up-to-date information about this optimization, refer to the [KEDA CHANGELOG](https://github.com/kedacore/keda/blob/main/CHANGELOG.md).\n\n## Expected Impact\n\nWith proper configuration and built-in optimizations, users typically experience:\n\n- **Reduced throttling messages**: Fewer \"client-side throttling\" warnings in KEDA operator logs\n- **Lower API server load**: Decreased request volume from KEDA operations to the Kubernetes API server\n- **Improved performance**: Better responsiveness in environments with 100+ ScaledObjects\n- **More stable scaling**: Consistent autoscaling behavior without throttling-related delays\n\n## Additional Troubleshooting\n\nBy carefully tuning these parameters and leveraging KEDA's built-in optimizations, you should be able to reduce or eliminate the client-side throttling experienced by the KEDA operator. If throttling persists even after these adjustments, consider:\n\n- Further investigation into the API server's capacity and resource allocation\n- Reviewing your ScaledObject configurations for potential optimizations\n- Consulting the KEDA community for environment-specific guidance\n\nIf issues continue, potential code-level optimizations within KEDA might be necessary, and feedback to the KEDA project maintainers would be valuable."
  },
  {
    "path": "content/troubleshooting/_index.md",
    "content": "---\n# Suppress the missing layout warning, pages are only rendered via troubleshooting shortcode.\nbuild:\n  render: false\n---\n"
  },
  {
    "path": "content/troubleshooting/aws-keda-operator-iam.md",
    "content": "+++\ntitle = \"Why does KEDA operator error with NoCredentialProviders\"\n+++\n\nIf you are running KEDA on AWS using IRSA or KIAM for pod identity and seeing the following error messages:\n\n```\nEvents:\n  Type     Reason                      Age                From           Message\n  ----     ------                      ----               ----           -------\n  Normal   KEDAScalersStarted          31s                keda-operator  Started scalers watch\n  Normal   KEDAScaleTargetDeactivated  31s                keda-operator  Deactivated apps/v1.Deployment default/my-event-based-deployment from 1 to 0\n  Normal   ScaledObjectReady           13s (x2 over 31s)  keda-operator  ScaledObject is ready for scaling\n  Warning  KEDAScalerFailed            1s (x2 over 31s)   keda-operator  NoCredentialProviders: no valid providers in chain. Deprecated.\n           For verbose messaging see aws.Config.CredentialsChainVerboseErrors\n```\n\nAnd the operator logs:\n\n```\n2021-11-02T23:50:29.688Z    ERROR    controller    Reconciler error    {\"reconcilerGroup\": \"keda.sh\", \"reconcilerKind\": \"ScaledObject\", \"controller\": \"scaledobject\", \"name\": \"my-event-based-deployment-scaledobject\", \"namespace\": \"default\"\n, \"error\": \"error getting scaler for trigger #0: error parsing SQS queue metadata: awsAccessKeyID not found\"}\n```\n\nThis means hat the KEDA operator is not receiving valid credentials, even before attempting to assume the IAM role associated with the `scaleTargetRef`.\n\nSome things to check:\n\n- Ensure the `keda-operator` deployment has the `iam.amazonaws.com/role` annotation under `deployment.spec.template.metadata` not `deployment.metadata` - if using KIAM\n- Ensure the `keda-operator` serviceAccount is annotated `eks.amazonaws.com/role-arn` - if using IRSA\n- Check `kiam-server` logs, successful provisioning of credentials looks like:\n`kube-system kiam-server-6bb67587bd-2f47p kiam-server {\"level\":\"info\",\"msg\":\"found role\",\"pod.iam.role\":\"arn:aws:iam::1234567890:role/my-service-role\",\"pod.ip\":\"100.64.7.52\",\"time\":\"2021-11-05T03:13:34Z\"}`.\n  - Use `grep` to filter the `kiam-server` logs, searching for the `keda-operator` pod ip.\n"
  },
  {
    "path": "content/troubleshooting/context-deadline-exceeded.md",
    "content": "+++\ntitle = \"Context Deadline Exceeded when `kubectl apply`?\"\nweight = 2\n+++\n\nIf you're encountering the following error when trying to apply a `ScaledObject` using the `kubectl apply` command:\n```sh\nkubectl apply -f nginx-scaledobject.yaml\n```\nAnd receive an error like:\n\n`Error from server (Timeout): error when applying patch:`\n`{\"metadata\":{\"annotations\":{\"kubectl.kubernetes.io/last-applied-configuration\":\"{\\\"apiVersion\\\":\\\"keda.sh/v1alpha1\\\",\\\"kind\\\":\\\"ScaledObject\\\",\\\"metadata\\\":{\\\"annotations\\\":{},\\\"name\\\":\\\"nginx-scaledobject\\\",\\\"namespace\\\":\\\"default\\\"},\\\"spec\\\":{\\\"cooldownPeriod\\\":300,\\\"maxReplicaCount\\\":2,\\\"minReplicaCount\\\":1,\\\"pollingInterval\\\":3,\\\"scaleTargetRef\\\":{\\\"name\\\":\\\"nginx-deploy\\\"},\\\"triggers\\\":[{\\\"metadata\\\":{\\\"type\\\":\\\"Utilization\\\",\\\"value\\\":\\\"90\\\"},\\\"type\\\":\\\"cpu\\\"}]}}\\n\"}},\"spec\":{\"maxReplicaCount\":2}}`\n`to:`\n`Resource: \"keda.sh/v1alpha1, Resource=scaledobjects\", GroupVersionKind: \"keda.sh/v1alpha1, Kind=ScaledObject\"`\n`Name: \"nginx-scaledobject\", Namespace: \"default\"`\n`for: \"nginx-scaledobject.yaml\": error when patching \"nginx-scaledobject.yaml\": Timeout: request did not complete within requested timeout - context deadline exceeded`.\n\n### Root cause\nThis issue commonly occurs when the KEDA admission webhook is not reachable by the Kubernetes control plane due to a network connectivity issue, typically on port 9443, which the webhook listens on.\n\n### Solution (For Managed Kubernetes Services)\n\n__Step 1__: Enable Debug Logging on the Webhook\nThis helps confirm whether the request is reaching the webhook.\n\n__Option A__: If KEDA was installed via Helm:\n\nUpdate your values.yaml file:\n```sh\nwebhooks:\n  level: debug\n```\nThen upgrade your Helm release:\n```sh\nhelm upgrade <release-name> kedacore/keda -n keda -f values.yaml\n```\n\n__Option B__: If KEDA was installed manually (without Helm):\n\nEdit the webhook deployment:\n```sh\nkubectl edit deployment keda-admission-webhooks -n keda\n```\nAdd or update the arguments to include:\n```sh\nargs:\n  - \"--zap-log-level=debug\"\n```\n\n__Step 2__: Check Webhook Logs\nTo confirm if the webhook is receiving the request:\n```sh\nkubectl logs -l app=keda-admission-webhooks -n keda\n```\nIf no logs appear when you run `kubectl apply`, it means the webhook pod is not being reached.\n\n\n__Step 3__: Check Network Connectivity\nEnsure port 9443 is open between:\n\n- The Kubernetes control plane (where `kubectl apply` runs)\n\n- The nodes hosting the `keda-admission-webhooks` pod\n\nThis often involves configuring firewall rules or security groups to allow traffic from the control plane IP range to the node IP range on port 9443.\n\n### Final Test:\nAfter opening port `9443`, try applying your ScaledObject again:\n```sh\nkubectl apply -f nginx-scaledobject.yaml\n```\nIf the webhook logs now show activity and the resource is created or properly rejected, the issue is resolved.\n"
  },
  {
    "path": "content/troubleshooting/gke-external-metrics.md",
    "content": "+++\ntitle = \"Why does Google Kubernetes Engine (GKE) 1.16 fail to fetch external metrics?\"\n+++\n\nIf you are running Google Kubernetes Engine (GKE) version 1.16, and are receiving the following error:\n\n```\nunable to fetch metrics from external metrics API: <METRIC>.external.metrics.k8s.io is forbidden: User \"system:vpa-recommender\" cannot list resource \"<METRIC>\" in API group \"external.metrics.k8s.io\" in the namespace \"<NAMESPACE>\": RBAC: clusterrole.rbac.authorization.k8s.io \"external-metrics-reader\" not found\n```\n\nYou are almost certainly running into a [known issue](https://issuetracker.google.com/issues/160597676). \n\nThe workaround is to recreate the `external-metrics-reader` role using the following YAML:\n\n```\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n  name: external-metrics-reader\nrules:\n- apiGroups:\n  - \"external.metrics.k8s.io\"\n  resources:\n  - \"*\"\n  verbs:\n  - list\n  - get\n  - watch\n```\n\nThe GKE team is currently working on a fix that they expect to have out in version >= 1.16.13.\n"
  },
  {
    "path": "content/troubleshooting/helm-upgrade-crd.md",
    "content": "+++\ntitle = \"Why is Helm not able to upgrade to v2.2.1 or above?\"\n+++\n\nOur initial approach to manage CRDs through Helm was not ideal given it didn't update existing CRDs.\n\nThis is a [known limitation of Helm](https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#install-a-crd-declaration-before-using-the-resource):\n\n> There is no support at this time for upgrading or deleting CRDs using Helm. This was an explicit decision after much community discussion due to the danger for unintentional data loss. Furthermore, there is currently no community consensus around how to handle CRDs and their lifecycle. As this evolves, Helm will add support for those use cases.\n\nAs of [v2.2.1](https://github.com/kedacore/charts/releases/tag/v2.2.1) of our Helm chart, we have changed our approach so that we automatically managing the CRDs through our Helm chart.\n\nDue to this transition, it can cause upgrade failures if you started using KEDA before v2.2.1 and will cause errors during upgrades such as the following:\n\n> Error: UPGRADE FAILED: rendered manifests contain a resource that already exists. Unable to continue with update: CustomResourceDefinition \"scaledobjects.keda.sh\" in namespace \"\" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key \"app.kubernetes.io/managed-by\": must be set to \"Helm\"; annotation validation error: missing key \"meta.helm.sh/release-name\": must be set to \"keda\"; annotation validation error: missing key \"meta.helm.sh/release-namespace\": must be set to \"keda\"\n\nIn order to fix this, you will need to manually add the following attributes to our CRDs:\n\n- `app.kubernetes.io/managed-by: Helm` label\n- `meta.helm.sh/release-name: keda` annotation\n- `meta.helm.sh/release-namespace: keda` annotation\n\nFuture upgrades should work seamlessly.\n"
  },
  {
    "path": "content/troubleshooting/istio-keda-faileddiscoverycheck.md",
    "content": "+++\ntitle = \"Why is KEDA API metrics server failing when Istio is installed?\"\n+++\n\nWhile setting up KEDA, you get an error: `(v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck` and you have [Istio](https://istio.io/) installed as service mesh in your cluster.\n\nThis can lead to side effects like not being able to delete namespaces in your cluster. You will see an error like:\n\n`NamespaceDeletionDiscoveryFailure - Discovery failed for some groups, 1 failing: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: the server is currently unable to handle the request`\n\n### Check the setup\n\nIn the following we assume that KEDA is installed in the namespace `keda`.\n\n#### Check the KEDA API service status\n\nFind the api service name for the service `keda/keda-metrics-apiserver`:\n\n```sh\nkubectl get apiservice --all-namespaces\n```\n\nCheck for the status of the api service found in previous step:\n\n```sh\nkubectl get apiservice <apiservicename> -o yaml\n```\n\nExample:\n\n```sh\nkubectl get apiservice v1beta1.external.metrics.k8s.io -o yaml\n```\n\nIf the status is `False`, then there seems to be an issue with the KEDA installation.\n\n#### Check Istio installation\n\nCheck if Istio is installed in your cluster:\n\n```sh\nkubectl get svc -n istio-system\n```\n\nIf Istio is installed you get a result like:\n\n```sh\nNAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                      AGE\nistio-ingressgateway   LoadBalancer   100.65.18.245    34.159.50.243   15021:31585/TCP,80:31669/TCP,443:30464/TCP   3d\nistiod                 ClusterIP      100.65.146.141   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP        3d\n```\n\n#### Check KEDA namespace labels\n\nCheck the KEDA namespace labels:\n\n```sh\nkubectl describe ns keda\n```\n\nIf Istio injection is enabled there is **no** label stating `istio-injection=disabled`.\n\nIn this setup the sidecar injection of Istio prevents the api service of KEDA to work properly.\n\n### Solution\n\nTo prevent the side-car injection of Istio we must label the namespace accordingly. This can be achieved via setting the label `istio-injection=disabled` to the namespace:\n\n```sh\nkubectl label namespace keda istio-injection=disabled\n```\n\nCheck that the label is set via `kubectl describe ns keda`\n\nInstall KEDA into the namespace `keda` and re-check the status of the api service which should now have the status `True`.\n"
  },
  {
    "path": "content/troubleshooting/keda-external-metrics-issue.md",
    "content": "+++\ntitle = \"Kubernetes Control plane is unable to communicate to Metric server?\"\nweight = 1\n+++\n\nIf while setting up KEDA, you get an error: `(v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck` with a message: `failing or missing response from https://POD-IP:6443/apis/external.metrics.k8s.io/v1beta1: Get \"https://POD-IP:6443/apis/external.metrics.k8s.io/v1beta1\": Address is not allowed`.\n\n One of the reason for this can be due to CNI like Cilium or any other.\n\n### Before you start\n\n- Make sure no network policies are blocking traffic and required CIDR's are added\n\n### Check the status:\n\nFind the api service name for the service `keda/keda-metrics-apiserver`:\n\n```sh\nkubectl get apiservice --all-namespaces\n```\n\nCheck for the status of the api service found in previous step:\n\n```sh\nkubectl get apiservice <apiservicename> -o yaml\n```\n\nExample:\n\n```sh\nkubectl get apiservice v1beta1.external.metrics.k8s.io -o yaml\n```\n\nIf the status is `False`, then there seems to be an issue and network might be the primary reason for it.\n\n\n### Solution for managed Kubernetes services:\n\nIn managed Kubernetes services you might solve the issue by updating deployment file of metric-apiserver as below.\n```yaml\n    dnsPolicy: ClusterFirst\n    hostNetwork: true\n```\nEg: [Modify](https://github.com/kedacore/charts/blob/f70e45e9a21e46036d51f8e16c2c63a7de8eea1b/keda/values.yaml#L42) useHostNetwork in values file.\n"
  },
  {
    "path": "content/troubleshooting/profiling-keda-components.md",
    "content": "+++\ntitle = \"Troubleshoot KEDA errors using profiling\"\n+++\n\nIn Golang we have the possibility to profile specific actions in order to determine what causes an issue.\nFor example, if our `keda-operator` pod is keeps getting OOM after a specific time, using profilig we can profile the heap and see what operatios taking all of this space.\n\nGolang support many profiling options like heap, cpu, goroutines and more... (for more info check this site https://pkg.go.dev/net/http/pprof).\n\nIn KEDA we provide the option to enable profiling on each component separately by enabling it using\nthe Helm chart and providing a port (if not enabled then it won't work).\n\n```yaml\nprofiling:\n  operator:\n    enabled: false\n    port: 8082\n  metricsServer:\n    enabled: false\n    port: 8083\n  webhooks:\n    enabled: false\n    port: 8084\n```\n\nIf not using the Helm chart then you can enable the profiling on each on of components by specifying the\nfollowing argument in the respective container\n```bash\n--profiling-bind-address=\":8082\"\n```\nand it will be exposed on the port you specified.\n\nAfter enabling it you can port-forward or expose the service and use tool like go tool pprof in order to get profiling data.\n\nFor more info look at this document https://go.dev/blog/pprof.\n"
  },
  {
    "path": "content/troubleshooting/proxy-network.md",
    "content": "+++\ntitle = \"Why is Kubernetes unable to get metrics from KEDA?\"\nweight = 1\n+++\n\nIf while setting up KEDA, you get an error: `(v1beta1.external.metrics.k8s.io) status FailedDiscoveryCheck` with a message: `no response from https://ip:443: Get https://ip:443: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`.\n\n One of the reason for this can be that you are behind a proxy network.\n\n### Before you start\n\n- Make sure no network policies are blocking traffic\n\n### Check the status\n\nFind the api service name for the service `keda/keda-metrics-apiserver`:\n\n```sh\nkubectl get apiservice --all-namespaces\n```\n\nCheck for the status of the api service found in previous step:\n\n```sh\nkubectl get apiservice <apiservicename> -o yaml\n```\n\nExample:\n\n```sh\nkubectl get apiservice v1beta1.external.metrics.k8s.io -o yaml\n```\n\nIf the status is `False`, then there seems to be an issue and proxy network might be the primary reason for it.\n\n### Solution for self-managed Kubernetes cluster\n\nFind the cluster IP for the `keda-metrics-apiserver` and `keda-operator-metrics`:\n\n```sh\nkubectl get services --all-namespaces\n```\n\nIn the `/etc/kubernetes/manifests/kube-apiserver.yaml` - add the cluster IPs found in the previous step in no_proxy variable.\n\nReload systemd manager configuration:\n\n```sh\nsudo systemctl daemon-reload\n```\n\nRestart kubelet:\n\n```sh\nsudo systemctl restart kubelet\n```\n\nCheck the API service status and the pods now. Should work!\n\n### Solution for managed Kubernetes services\n\nIn managed Kubernetes services you might solve the issue by updating firewall rules in your cluster.\n\n#### Google Kubernetes Engine (GKE)\n\nE.g. in GKE private cluster [add](https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#add_firewall_rules) port 6443 (kube-apiserver) to allowed ports in master node firewall rules.\n\nAlso, if you are using Network Policies in your `kube-system` namespace, make sure they don't block access for the konnectivity agent via port 6443. You can read more about [konnectivity service](https://kubernetes.io/docs/concepts/architecture/control-plane-node-communication/#konnectivity-service).\n\nIn that case, you need to add a similar NetworkPolicy in the `kube-system` namespace:\n\n```yaml\n---\napiVersion: networking.k8s.io/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-egress-from-konnectivity-agent-to-keda\n  namespace: kube-system\nspec:\n  egress:\n  - ports:\n    - port: 6443\n      protocol: TCP\n    to:\n    - ipBlock:\n        cidr: ${KUBE_POD_IP_CIDR}\n  podSelector:\n    matchLabels:\n      k8s-app: konnectivity-agent\n  policyTypes:\n  - Egress\n```\n\n#### Amazon Elastic Kubernetes Service (EKS)\n\nE.g. Make sure the Cluster Security group can reach the Nodegroups on TCP 6443. For example, using the [terraform eks module](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest), this is achievable through the addtional nodegroup rules\n\n```terraform\nmodule \"eks\" {\n  source                               = \"terraform-aws-modules/eks/aws\"\n  version                              = \"19.5.1\"\n  ...\n  create_node_security_group = true\n  node_security_group_additional_rules = {\n    keda_metrics_server_access = {\n      description                   = \"Cluster access to keda metrics\"\n      protocol                      = \"tcp\"\n      from_port                     = 6443\n      to_port                       = 6443\n      type                          = \"ingress\"\n      source_cluster_security_group = true\n    }\n  }\n```\n\nAs of version `19.6.0` of the `terraform-aws-modules/eks/aws` module it is enough to have `node_security_group_enable_recommended_rules` option enabled(default) to get neccessary security group ingress rule.\n"
  },
  {
    "path": "content/troubleshooting/scaledobject-not-scale.md",
    "content": "+++\ntitle = \"Why is my `ScaledObject` paused?\"\nweight = 1\n+++\n\nWhen KEDA has upstream errors to get scaler source information it will keep the current instance count of the workload unless the `fallback` section is defined.\n\nThis behavior might feel like the autoscaling is not happening, but in reality, it is because of problems related to the scaler source.\n\nYou can check if this is your case by reviewing the logs from the KEDA pods where you should see errors in both our Operator and Metrics server. You can also check a status of the ScaledObject (`READY` and `ACTIVE` condition) by running following command:\n\n```bash\n$ kubectl get scaledobject MY-SCALED-OBJECT\n```\n"
  },
  {
    "path": "content/videos.md",
    "content": "+++\ntitle = \"Videos\"\ndescription = \"Videos about using KEDA\"\n+++\n\n## KEDA: Unlocking Advanced Event-Driven Scaling for Kubernetes (KubeCon Europe 2025)\n\n{{< youtube id=\"317rLOIKfDQ\" >}}\n\n## Scaling New Heights with KEDA: Performance, Extensions, and Beyond (KubeCon Europe 2024)\n\n{{< youtube id=\"_5_njiPr5vg\" >}}\n\n## Exploring KEDA's Graduation and Advancements in Event-Driven Scaling (KubeCon North America 2023)\n\n{{< youtube id=\"wYQ2cvSj6os\" >}}\n\n### Unlocking the Potential of KEDA: New Features and Best Practices (KubeCon Europe 2023)\n\n{{< youtube id=\"Db3UcxXbsvw\" >}}\n\n### Real Time And Serverless Scaling In Kubernetes (KubeCon North America 2022)\n\n{{< youtube id=\"vjKLbfEZ7MU\" >}}"
  },
  {
    "path": "data/faq.toml",
    "content": "[[qna]]\nq = \"What is KEDA and why is it useful?\"\na = \"KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources.\"\n\n[[qna]]\nq = \"What are the prerequisites for using KEDA?\"\na = \"\"\"\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA releases are tested against specific Kubernetes versions. Refer to the documentation for the tested versions for your KEDA release.\n\nKEDA uses a CRD (custom resource definition) and the Kubernetes metric server, so you will need a Kubernetes version that supports these components.\n\"\"\"\n\n[[qna]]\nq = \"Does KEDA depend on any Azure service?\"\na = \"No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure.\"\n\n[[qna]]\nq = \"Does KEDA only work with Azure Functions?\"\na = \"No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container.\"\n\n[[qna]]\nq = \"Why should we use KEDA if we are already using Azure Functions in Azure?\"\na = \"\"\"\nThere are a few reasons for this:\n\n* Run functions on-premises (potentially in something like an 'intelligent edge' architecture)\n* Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)\n* Run functions outside of Azure (no vendor lock-in)\n* Specific need for more control (GPU enabled compute clusters, policies, etc.)\n\"\"\"\n\n[[qna]]\nq = \"Can I scale my HTTP container or function with KEDA and Kubernetes?\"\na = \"\"\"\nKEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads.\n\nWe recommend using the [Prometheus scaler](/scalers/prometheus/) to create scale rule based on metrics around HTTP events for now. Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more.\n\"\"\"\n\n[[qna]]\nq = \"Where can I get to the code for the Scalers?\"\na = \"All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers).\"\n\n[[qna]]\nq = \"Is short polling intervals a problem?\"\na = \"Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA.\"\n\n[[qna]]\nq = \"How can I get involved?\"\na = \"\"\"\nThere are several ways to get involved.\n\n* Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted)\n* We are always looking to add more scalers.\n* We are always looking for more samples, documentation, etc.\n* Please join us in our [weekly standup](https://github.com/kedacore/keda#community).\n\"\"\"\n\n[[qna]]\nq = \"Can KEDA be used in production?\"\na = \"Yes! KEDA is now 1.0 and suited for production workloads.\"\n\n[[qna]]\nq = \"What does it cost?\"\na = \"There is no charge for using KEDA itself.\"\n\n\n[[qna]]\nq = \"How do I access KEDA resources using `client-go`?\"\na = \"\"\"\nKEDA resources can be accessed using the [dynamic\nclient](https://godoc.org/k8s.io/client-go/dynamic) from the `client-go` package.  The dynamic client's `Resource()` method accepts a\n[GroupVersionResource](https://godoc.org/k8s.io/apimachinery/pkg/runtime/schema#GroupVersionResource)\ndescribing the type of resource to be accessed and returns a\n[NamespaceableResourceInterface](https://godoc.org/k8s.io/client-go/dynamic#NamespaceableResourceInterface)\nwhich contains methods to retrieve, create, or manipulate that resource.  Here's a code sample\ncontaining a function that retrieves a KEDA `ScaledObject` resource by name.\n\n```go\npackage main\n\nimport (\n\t\"fmt\"\n\tmetav1 \"k8s.io/apimachinery/pkg/apis/meta/v1\"\n\t\"k8s.io/apimachinery/pkg/runtime/schema\"\n\t\"k8s.io/client-go/dynamic\"\n\t_ \"k8s.io/client-go/plugin/pkg/client/auth/gcp\"\n\t\"k8s.io/client-go/tools/clientcmd\"\n\t\"os\"\n)\n\nvar (\n\tkedaGVR = schema.GroupVersionResource{\n\t\tGroup:    \"keda.k8s.io\",\n\t\tVersion:  \"v1alpha1\",\n\t\tResource: \"scaledobjects\",\n\t}\n)\n\nfunc GetScaledObjectByName(name string) {\n\tconfig, err := clientcmd.BuildConfigFromFlags(\"\", os.Getenv(\"HOME\")+\"/.kube/config\")\n\tdynClient, err := dynamic.NewForConfig(config)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\tscaledObjectClient := dynClient.Resource(kedaGVR)\n\tscaledObject, err := scaledObjectClient.Namespace(\"default\").Get(name, metav1.GetOptions{})\n\tif err != nil {\n\t\tfmt.Printf(\"Error retrieving scaledobjects: %s\\n\", err)\n\t} else {\n\t\tfmt.Printf(\"Got ScaledObject:\\n %v\", scaledObject)\n\t}\n}\n```\n\"\"\"\n"
  },
  {
    "path": "data/faq20.toml",
    "content": "[[qna]]\nq = \"What is KEDA and why is it useful?\"\na = \"KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources.\"\ntype = \"General\"\n\n[[qna]]\nq = \"What are the prerequisites for using KEDA?\"\na = \"\"\"\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release.\n\nIt uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these.\n\n> 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running.\n\"\"\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can KEDA be used in production?\"\na = \"Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well..\"\ntype = \"General\"\n\n[[qna]]\nq = \"What does it cost?\"\na = \"There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible.\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can I scale HTTP workloads with KEDA and Kubernetes?\"\na = \"\"\"\nKEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box.\n\nWe do, however, provide some alternative approaches:\n- Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on))\n- Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events\n  - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more.\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Is short polling intervals a problem?\"\na = \"Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA.\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Using multiple triggers for the same scale target\"\na = \"\"\"\nKEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`.\n\nBy doing this, your autoscaling becomes better:\n- All your autoscaling rules are in one place\n- You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other\n\nKEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)\"\na = \"\"\"\nWe recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload.\n\nThey will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior.\n\nIf you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?\"\na = \"\"\"\nThe target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions.\n\nThe current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works.\n\nBy default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers).\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Why does KEDA use external metrics and not custom metrics instead?\"\na = \"\"\"\nKubernetes allows you to autoscale based on custom & external metrics which are fundamentally different:\n- **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus)\n- **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.)\n\nBecause KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics.\n\nThis is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality.\n\nRead [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple metric servers serving external metrics in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nKubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics.\n\nIf you want to know what external metric server is currently registered, you can use the following command:\n\n```shell\n~  kubectl  get APIService/v1beta1.external.metrics.k8s.io\nNAME                              SERVICE                                       AVAILABLE   AGE\nv1beta1.external.metrics.k8s.io   keda-system/keda-operator-metrics-apiserver   True        457d\n```\n\nOnce a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored.\n\nThere is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple installations of KEDA in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nThis is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics.\n\nAlso, KEDA does not allow you to share a single metric server across multiple operator installations.\n\nLearn more in the \"Can I run multiple metric servers serving external metrics in the same cluster?\" FAQ entry.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"How can I get involved?\"\na = \"\"\"\nThere are several ways to get involved.\n\n* Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted)\n* We are always looking to add more scalers.\n* We are always looking for more samples, documentation, etc.\n* Please join us in our [weekly standup](https://github.com/kedacore/keda#community).\n\"\"\"\ntype = \"Community\"\n\n[[qna]]\nq = \"Where can I get to the code for the Scalers?\"\na = \"All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers).\"\ntype = \"Community\"\n\n[[qna]]\nq = \"How do I access KEDA resources using `client-go`?\"\na = \"\"\"KEDA client-go is exported as part of the KEDA repository.\"\"\"\n\n[[qna]]\nq = \"How do I run KEDA with `readOnlyRootFilesystem=true`?\"\na = \"\"\"\nAs default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention.\n\nIf you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system.\nTo overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment.\nTo use your certificate, you need to reference it in the container `args` section, e.g.:\n```\nargs:\n  - '--client-ca-file=/cabundle/service-ca.crt'\n  - '--tls-cert-file=/certs/tls.crt'\n  - '--tls-private-key-file=/certs/tls.key'\n```\nIt is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where,\nby default, metrics server writes its generated cert. The corresponding helm command is:\n```\nhelm install keda kedacore/keda --namespace keda \\\n  --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \\\n  --set 'securityContext.metricServer.readOnlyRootFilesystem=true'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"How do I run KEDA with TLS v1.3 only?\"\na = \"\"\"\nBy default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites.\nIn some environments, these ciphers may be considered less secure, for example CBC ciphers.\n\nAs an alternative, you can configure the minimum TLS version to be v1.3 to increase security.\nSince all modern clients support this version, there should be no impact in most scenarios.\n\nYou can set this with args - e.g.:\n```\nargs:\n  - '--tls-min-version=VersionTLS13'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Does KEDA depend on any Azure service?\"\na = \"No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does KEDA only work with Azure Functions?\"\na = \"No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Why should we use KEDA if we are already using Azure Functions in Azure?\"\na = \"\"\"\nThere are a few reasons for this:\n\n* Run functions on-premises (potentially in something like an 'intelligent edge' architecture)\n* Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)\n* Run functions outside of Azure (no vendor lock-in)\n* Specific need for more control (GPU enabled compute clusters, policies, etc.)\n\"\"\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does scaler search support wildcard search?\"\na = \"Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query.\"\ntype = \"Website\"\n"
  },
  {
    "path": "data/faq2_14.toml",
    "content": "[[qna]]\nq = \"What is KEDA and why is it useful?\"\na = \"KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources.\"\ntype = \"General\"\n\n[[qna]]\nq = \"What are the prerequisites for using KEDA?\"\na = \"\"\"\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release.\n\nIt uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these.\n\n> 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running.\n\"\"\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can KEDA be used in production?\"\na = \"Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well..\"\ntype = \"General\"\n\n[[qna]]\nq = \"What does it cost?\"\na = \"There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible.\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can I scale HTTP workloads with KEDA and Kubernetes?\"\na = \"\"\"\nKEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box.\n\nWe do, however, provide some alternative approaches:\n- Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on))\n- Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events\n  - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more.\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Is short polling intervals a problem?\"\na = \"Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA.\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Using multiple triggers for the same scale target\"\na = \"\"\"\nKEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`.\n\nBy doing this, your autoscaling becomes better:\n- All your autoscaling rules are in one place\n- You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other\n\nKEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)\"\na = \"\"\"\nWe recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload.\n\nThey will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior.\n\nIf you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?\"\na = \"\"\"\nThe target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions.\n\nThe current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works.\n\nBy default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers).\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Why does KEDA use external metrics and not custom metrics instead?\"\na = \"\"\"\nKubernetes allows you to autoscale based on custom & external metrics which are fundamentally different:\n- **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus)\n- **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.)\n\nBecause KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics.\n\nThis is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality.\n\nRead [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple metric servers serving external metrics in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nKubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics.\n\nIf you want to know what external metric server is currently registered, you can use the following command:\n\n```shell\n~  kubectl  get APIService/v1beta1.external.metrics.k8s.io\nNAME                              SERVICE                                       AVAILABLE   AGE\nv1beta1.external.metrics.k8s.io   keda-system/keda-operator-metrics-apiserver   True        457d\n```\n\nOnce a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored.\n\nThere is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple installations of KEDA in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nThis is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics.\n\nAlso, KEDA does not allow you to share a single metric server across multiple operator installations.\n\nLearn more in the \"Can I run multiple metric servers serving external metrics in the same cluster?\" FAQ entry.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"How can I get involved?\"\na = \"\"\"\nThere are several ways to get involved.\n\n* Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted)\n* We are always looking to add more scalers.\n* We are always looking for more samples, documentation, etc.\n* Please join us in our [weekly standup](https://github.com/kedacore/keda#community).\n\"\"\"\ntype = \"Community\"\n\n[[qna]]\nq = \"Where can I get to the code for the Scalers?\"\na = \"All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers).\"\ntype = \"Community\"\n\n[[qna]]\nq = \"How do I access KEDA resources using `client-go`?\"\na = \"\"\"KEDA client-go is exported as part of the KEDA repository.\"\"\"\n\n[[qna]]\nq = \"How do I run KEDA with `readOnlyRootFilesystem=true`?\"\na = \"\"\"\nAs default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention.\n\nIf you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system.\nTo overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment.\nTo use your certificate, you need to reference it in the container `args` section, e.g.:\n```\nargs:\n  - '--client-ca-file=/cabundle/service-ca.crt'\n  - '--tls-cert-file=/certs/tls.crt'\n  - '--tls-private-key-file=/certs/tls.key'\n```\nIt is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where,\nby default, metrics server writes its generated cert. The corresponding helm command is:\n```\nhelm install keda kedacore/keda --namespace keda \\\n  --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \\\n  --set 'securityContext.metricServer.readOnlyRootFilesystem=true'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"How do I run KEDA with TLS v1.3 only?\"\na = \"\"\"\nBy default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites.\nIn some environments, these ciphers may be considered less secure, for example CBC ciphers.\n\nAs an alternative, you can configure the minimum TLS version to be v1.3 to increase security.\nSince all modern clients support this version, there should be no impact in most scenarios.\n\nYou can set this with args - e.g.:\n```\nargs:\n  - '--tls-min-version=VersionTLS13'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Does KEDA depend on any Azure service?\"\na = \"No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does KEDA only work with Azure Functions?\"\na = \"No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Why should we use KEDA if we are already using Azure Functions in Azure?\"\na = \"\"\"\nThere are a few reasons for this:\n\n* Run functions on-premises (potentially in something like an 'intelligent edge' architecture)\n* Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)\n* Run functions outside of Azure (no vendor lock-in)\n* Specific need for more control (GPU enabled compute clusters, policies, etc.)\n\"\"\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does scaler search support wildcard search?\"\na = \"Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query.\"\ntype = \"Website\"\n"
  },
  {
    "path": "data/faq2_15.toml",
    "content": "[[qna]]\nq = \"What is KEDA and why is it useful?\"\na = \"KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources.\"\ntype = \"General\"\n\n[[qna]]\nq = \"What are the prerequisites for using KEDA?\"\na = \"\"\"\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release.\n\nIt uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these.\n\n> 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running.\n\"\"\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can KEDA be used in production?\"\na = \"Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well..\"\ntype = \"General\"\n\n[[qna]]\nq = \"What does it cost?\"\na = \"There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible.\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can I scale HTTP workloads with KEDA and Kubernetes?\"\na = \"\"\"\nKEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box.\n\nWe do, however, provide some alternative approaches:\n- Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on))\n- Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events\n  - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more.\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Is short polling intervals a problem?\"\na = \"Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA.\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Using multiple triggers for the same scale target\"\na = \"\"\"\nKEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`.\n\nBy doing this, your autoscaling becomes better:\n- All your autoscaling rules are in one place\n- You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other\n\nKEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)\"\na = \"\"\"\nWe recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload.\n\nThey will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior.\n\nIf you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?\"\na = \"\"\"\nThe target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions.\n\nThe current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works.\n\nBy default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers).\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Why does KEDA use external metrics and not custom metrics instead?\"\na = \"\"\"\nKubernetes allows you to autoscale based on custom & external metrics which are fundamentally different:\n- **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus)\n- **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.)\n\nBecause KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics.\n\nThis is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality.\n\nRead [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple metric servers serving external metrics in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nKubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics.\n\nIf you want to know what external metric server is currently registered, you can use the following command:\n\n```shell\n~  kubectl  get APIService/v1beta1.external.metrics.k8s.io\nNAME                              SERVICE                                       AVAILABLE   AGE\nv1beta1.external.metrics.k8s.io   keda-system/keda-operator-metrics-apiserver   True        457d\n```\n\nOnce a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored.\n\nThere is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple installations of KEDA in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nThis is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics.\n\nAlso, KEDA does not allow you to share a single metric server across multiple operator installations.\n\nLearn more in the \"Can I run multiple metric servers serving external metrics in the same cluster?\" FAQ entry.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"How can I get involved?\"\na = \"\"\"\nThere are several ways to get involved.\n\n* Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted)\n* We are always looking to add more scalers.\n* We are always looking for more samples, documentation, etc.\n* Please join us in our [weekly standup](https://github.com/kedacore/keda#community).\n\"\"\"\ntype = \"Community\"\n\n[[qna]]\nq = \"Where can I get to the code for the Scalers?\"\na = \"All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers).\"\ntype = \"Community\"\n\n[[qna]]\nq = \"How do I access KEDA resources using `client-go`?\"\na = \"\"\"KEDA client-go is exported as part of the KEDA repository.\"\"\"\n\n[[qna]]\nq = \"How do I run KEDA with `readOnlyRootFilesystem=true`?\"\na = \"\"\"\nAs default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention.\n\nIf you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system.\nTo overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment.\nTo use your certificate, you need to reference it in the container `args` section, e.g.:\n```\nargs:\n  - '--client-ca-file=/cabundle/service-ca.crt'\n  - '--tls-cert-file=/certs/tls.crt'\n  - '--tls-private-key-file=/certs/tls.key'\n```\nIt is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where,\nby default, metrics server writes its generated cert. The corresponding helm command is:\n```\nhelm install keda kedacore/keda --namespace keda \\\n  --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \\\n  --set 'securityContext.metricServer.readOnlyRootFilesystem=true'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"How do I run KEDA with TLS v1.3 only?\"\na = \"\"\"\nBy default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites.\nIn some environments, these ciphers may be considered less secure, for example CBC ciphers.\n\nAs an alternative, you can configure the minimum TLS version to be v1.3 to increase security.\nSince all modern clients support this version, there should be no impact in most scenarios.\n\nYou can set this with args - e.g.:\n```\nargs:\n  - '--tls-min-version=VersionTLS13'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Does KEDA depend on any Azure service?\"\na = \"No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does KEDA only work with Azure Functions?\"\na = \"No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Why should we use KEDA if we are already using Azure Functions in Azure?\"\na = \"\"\"\nThere are a few reasons for this:\n\n* Run functions on-premises (potentially in something like an 'intelligent edge' architecture)\n* Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)\n* Run functions outside of Azure (no vendor lock-in)\n* Specific need for more control (GPU enabled compute clusters, policies, etc.)\n\"\"\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does scaler search support wildcard search?\"\na = \"Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query.\"\ntype = \"Website\"\n"
  },
  {
    "path": "data/faq2_19.toml",
    "content": "[[qna]]\nq = \"What is KEDA and why is it useful?\"\na = \"KEDA stands for Kubernetes Event-driven Autoscaler. It is built to be able to activate a Kubernetes deployment (i.e. no pods to a single pod) and subsequently to more pods based on events from various event sources.\"\ntype = \"General\"\n\n[[qna]]\nq = \"What are the prerequisites for using KEDA?\"\na = \"\"\"\nKEDA is community-supported. For all support options, see the [Support](/support/) page.\n\nKEDA releases are tested against specific Kubernetes versions. Refer to the Kubernetes compatibility documentation for the tested versions for your KEDA release.\n\nIt uses a CRD (custom resource definition) and the Kubernetes metric server so you will have to use a Kubernetes version which supports these.\n\n> 💡 Older KEDA releases may be tested on older Kubernetes versions. Check the compatibility matrix for the KEDA release you are running.\n\"\"\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can KEDA be used in production?\"\na = \"Yes! KEDA v2.0 is suited for production workloads, but we still support v1.5 if you are running that as well..\"\ntype = \"General\"\n\n[[qna]]\nq = \"What does it cost?\"\na = \"There is no charge for using KEDA itself, we just ask people to [become a listed user](https://github.com/kedacore/keda-docs#become-a-listed-keda-user) when possible.\"\ntype = \"General\"\n\n[[qna]]\nq = \"Can I scale HTTP workloads with KEDA and Kubernetes?\"\na = \"\"\"\nKEDA will scale a container using metrics from a scaler, but unfortunately there is no scaler today for HTTP workloads out-of-the-box.\n\nWe do, however, provide some alternative approaches:\n- Use our HTTP add-on scaler which is currently in experimental stage ([GitHub](https://github.com/kedacore/http-add-on))\n- Use [Prometheus scaler](/docs/latest/scalers/prometheus/) to create scale rule based on metrics around HTTP events\n  - Read [Anirudh Garg's blog post](https://dev.to/anirudhgarg_99/scale-up-and-down-a-http-triggered-function-app-in-kubernetes-using-keda-4m42) to learn more.\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Is short polling intervals a problem?\"\na = \"Polling interval really only impacts the time-to-activation (scaling from 0 to 1) but once scaled to one it's really up to the HPA (horizontal pod autoscaler) which polls KEDA.\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Using multiple triggers for the same scale target\"\na = \"\"\"\nKEDA allows you to use multiple triggers as part of the same `ScaledObject` or `ScaledJob`.\n\nBy doing this, your autoscaling becomes better:\n- All your autoscaling rules are in one place\n- You will not have multiple `ScaledObject`'s or `ScaledJob`'s interfering with each other\n\nKEDA will start scaling as soon as when one of the triggers meets the criteria. Horizontal Pod Autoscaler (HPA) will calculate metrics for every scaler and use the highest desired replica count to scale the workload to.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"Don't combine `ScaledObject` with Horizontal Pod Autoscaler (HPA)\"\na = \"\"\"\nWe recommend not to combine using KEDA's `ScaledObject` with a Horizontal Pod Autoscaler (HPA) to scale the same workload.\n\nThey will compete with each other resulting given KEDA uses Horizontal Pod Autoscaler (HPA) under the hood and will result in odd scaling behavior.\n\nIf you are using a Horizontal Pod Autoscaler (HPA) to scale on CPU and/or memory, we recommend using the [CPU scaler](/docs/latest/scalers/cpu/) & [Memory scaler](/docs/latest/scalers/memory/) scalers instead.\n\"\"\"\ntype = \"Best Practices\"\n\n[[qna]]\nq = \"What does the target metric value in the Horizontal Pod Autoscaler (HPA) represent?\"\na = \"\"\"\nThe target metric value is used by the Horizontal Pod Autoscaler (HPA) to make scaling decisions.\n\nThe current target value on the Horizontal Pod Autoscaler (HPA) often does not match with the metrics on the system you are scaling on. This is because of how the Horizontal Pod Autoscaler's (HPA) [scaling algorithm](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) works.\n\nBy default, KEDA scalers use average metrics (the `AverageValue` metric type). This means that the HPA will use the average value of the metric between the total amount of pods. As of KEDA v2.7, ScaledObjects also support the `Value` metric type. You can learn more about it [here](https://keda.sh/docs/latest/concepts/scaling-deployments/#triggers).\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Why does KEDA use external metrics and not custom metrics instead?\"\na = \"\"\"\nKubernetes allows you to autoscale based on custom & external metrics which are fundamentally different:\n- **Custom metrics** are metrics that come from applications solely running on the Kubernetes cluster (Prometheus)\n- **External metrics** are metrics that represent the state of an application/service that is running outside of the Kubernetes cluster (AWS, Azure, GCP, Datadog, etc.)\n\nBecause KEDA primarily serves metrics for metric sources outside of the Kubernetes cluster, it uses external metrics and not custom metrics.\n\nThis is why KEDA registers the `v1beta1.external.metrics.k8s.io` namespace in the API service. However, this is just an implementation detail as both offer the same functionality.\n\nRead [about the different metric APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis) or [this article](https://cloud.google.com/kubernetes-engine/docs/concepts/custom-and-external-metrics) by Google Cloud to learn more.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple metric servers serving external metrics in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nKubernetes currently only supports one metric server serving `external.metrics.k8s.io` metrics per cluster. This is because only one API Service can be registered to handle external metrics.\n\nIf you want to know what external metric server is currently registered, you can use the following command:\n\n```shell\n~  kubectl  get APIService/v1beta1.external.metrics.k8s.io\nNAME                              SERVICE                                       AVAILABLE   AGE\nv1beta1.external.metrics.k8s.io   keda-system/keda-operator-metrics-apiserver   True        457d\n```\n\nOnce a new metric server is installed, it will overwrite the existing API Server registration and take over the `v1beta1.external.metrics.k8s.io` namespace. This will cause the previously installed metric server to be ignored.\n\nThere is an [open proposal](https://github.com/kubernetes-sigs/custom-metrics-apiserver/issues/70) to allow multiple metric servers in the same cluster, but it's not implemented yet.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"Can I run multiple installations of KEDA in the same cluster?\"\na = \"\"\"\nUnfortunately, you cannot do that.\n\nThis is a limitation that is because Kubernetes does not allow you to run multiple metric servers in the same cluster that serve external metrics.\n\nAlso, KEDA does not allow you to share a single metric server across multiple operator installations.\n\nLearn more in the \"Can I run multiple metric servers serving external metrics in the same cluster?\" FAQ entry.\n\"\"\"\ntype = \"Kubernetes\"\n\n[[qna]]\nq = \"How can I get involved?\"\na = \"\"\"\nThere are several ways to get involved.\n\n* Pick up an issue to work on. A good place to start might be issues which are marked as [Good First Issue](https://github.com/kedacore/keda/labels/good%20first%20issue) or [Help Wanted](https://github.com/kedacore/keda/labels/help%20wanted)\n* We are always looking to add more scalers.\n* We are always looking for more samples, documentation, etc.\n* Please join us in our [weekly standup](https://github.com/kedacore/keda#community).\n\"\"\"\ntype = \"Community\"\n\n[[qna]]\nq = \"Where can I get to the code for the Scalers?\"\na = \"All scalers have their code [here](https://github.com/kedacore/keda/tree/main/pkg/scalers).\"\ntype = \"Community\"\n\n[[qna]]\nq = \"How do I access KEDA resources using `client-go`?\"\na = \"\"\"KEDA client-go is exported as part of the KEDA repository.\"\"\"\n\n[[qna]]\nq = \"How do I run KEDA with `readOnlyRootFilesystem=true`?\"\na = \"\"\"\nAs default, KEDA v2.10 or above sets `readOnlyRootFilesystem=true` as default without any other manual intervention.\n\nIf you are running KEDA v2.9 or below, you can't run KEDA with `readOnlyRootFilesystem=true` as default because Metrics adapter generates self-signed certificates during deployment and stores them on the root file system.\nTo overcome this, you can create a secret/configmap with a valid CA, cert and key and then mount it to the Metrics Deployment.\nTo use your certificate, you need to reference it in the container `args` section, e.g.:\n```\nargs:\n  - '--client-ca-file=/cabundle/service-ca.crt'\n  - '--tls-cert-file=/certs/tls.crt'\n  - '--tls-private-key-file=/certs/tls.key'\n```\nIt is also possible to run KEDA with `readOnlyRootFilesystem=true` by creating an emptyDir volume and mounting it to the path where,\nby default, metrics server writes its generated cert. The corresponding helm command is:\n```\nhelm install keda kedacore/keda --namespace keda \\\n  --set 'volumes.metricsApiServer.extraVolumes[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].name=keda-volume' \\\n  --set 'volumes.metricsApiServer.extraVolumeMounts[0].mountPath=/apiserver.local.config/certificates/' \\\n  --set 'securityContext.metricServer.readOnlyRootFilesystem=true'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"How do I run KEDA with TLS v1.3 only?\"\na = \"\"\"\nBy default, Keda listens on TLS v1.1 and TLSv1.2, with the default Golang ciphersuites.\nIn some environments, these ciphers may be considered less secure, for example CBC ciphers.\n\nAs an alternative, you can configure the minimum TLS version to be v1.3 to increase security.\nSince all modern clients support this version, there should be no impact in most scenarios.\n\nYou can set this with args - e.g.:\n```\nargs:\n  - '--tls-min-version=VersionTLS13'\n```\n\"\"\"\ntype = \"Features\"\n\n[[qna]]\nq = \"Does KEDA depend on any Azure service?\"\na = \"No, KEDA only takes a dependency on standard Kubernetes constructs and can run on any Kubernetes cluster whether in OpenShift, AKS, GKE, EKS or your own infrastructure.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does KEDA only work with Azure Functions?\"\na = \"No, KEDA can scale up/down any container that you specify in your deployment. There has been work done in the Azure Functions tooling to make it easy to scale an Azure Function container.\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Why should we use KEDA if we are already using Azure Functions in Azure?\"\na = \"\"\"\nThere are a few reasons for this:\n\n* Run functions on-premises (potentially in something like an 'intelligent edge' architecture)\n* Run functions alongside other Kubernetes apps (maybe in a restricted network, app mesh, custom environment, etc.)\n* Run functions outside of Azure (no vendor lock-in)\n* Specific need for more control (GPU enabled compute clusters, policies, etc.)\n\"\"\"\ntype = \"Azure\"\n\n[[qna]]\nq = \"Does scaler search support wildcard search?\"\na = \"Yes. The search actually supports wildcard search. We've made our search to automatically perform wildcard filtering on the fly so you don't have to append special symbols within your search query.\"\ntype = \"Website\"\n"
  },
  {
    "path": "hugo.toml",
    "content": "baseURL = \"https://keda.sh\"\nlanguageCode = \"en-us\"\ntitle = \"KEDA\"\nenableGitInfo = true\ndisableKinds = [\"taxonomy\", \"term\"]\n\n[services.googleAnalytics]\nid = 'G-YSWMV22VTQ'\n\n# See other available styles here: https://xyproto.github.io/splash/docs/\n[markup.highlight]\nstyle = \"dracula\"\n\n[params]\n# Main page hero\ntagline = \"Kubernetes Event-driven Autoscaling\"\ndescription = \"Application autoscaling made simple\"\n\n# \"What is KEDA?\" section on main page\nwhat_is = \"\"\"\n**KEDA** is a [Kubernetes](https://kubernetes.io)-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed.\n\n**KEDA** is a single-purpose and lightweight component that can be added into any Kubernetes cluster. KEDA works alongside standard Kubernetes components like the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and can extend functionality without overwriting or duplication. With KEDA, you can explicitly map the apps you want to use event-driven scale, with other apps continuing to function. This makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.\n\"\"\"\n\nlocale = \"en_US\"\ntwitter_handle = \"kedaorg\"\nfavicon = \"favicon.png\"\n\n[params.docsearch]\nappId = \"3IFB1FERQT\"\napiKey = \"0e8dd1123a0df5e715fc587ee0930782\" # notsecret\nindexName = \"keda\"\n\n[params.versions]\ndocs = [\n  \"2.19\",\n  \"2.18\",\n  \"2.17\",\n  \"2.16\",\n  \"2.15\",\n  \"2.14\",\n  \"2.13\",\n  \"2.12\",\n  \"2.11\",\n  \"2.10\",\n  \"2.9\",\n  \"2.8\",\n  \"2.7\",\n  \"2.6\",\n  \"2.5\",\n  \"2.4\",\n  \"2.3\",\n  \"2.2\",\n  \"2.1\",\n  \"2.0\",\n  \"1.5\",\n  \"1.4\",\n]\nhttp-add-on = [\"0.14\"]\n\n[params.unreleased]\ndocs = [\"2.20\"]\nhttp-add-on = []\n\n# Site fonts served from @fontsource npm packages (see module mounts).\n# Browse available options at https://fonts.google.com.\n[[params.fonts]]\nname = \"Inria Sans\"\nsizes = [300, 400, 700]\ntype = \"sans_serif\"\n\n[[params.fonts]]\nname = \"Roboto Mono\"\nsizes = [300, 400, 600, 700]\ntype = \"monospace\"\n\n# All logos are in static/img/logos\n[params.logos]\nnavbar = \"keda-horizontal-color.png\"\nhero = \"keda-icon-color.png\"\nfooter = \"keda-icon-white.png\"\n\n[mediaTypes.\"text/netlify\"]\ndelimiter = \"\"\n\n[outputFormats.REDIRECTS]\nmediaType = \"text/netlify\"\nbaseName = \"_redirects\"\n\n[outputs]\nhome = [\"HTML\", \"RSS\", \"REDIRECTS\", \"Lunr\"]\n\n[outputFormats.Lunr]\nbaseName = \"index\"\nisPlainText = true\nmediaType = \"application/json\"\nnotAlternative = true\n\n# parameters for lunr search\n[params.lunr]\nvars = [\n  \"title\",\n  \"maintainer\",\n  \"description\",\n  \"availability\",\n  \"category\",\n  \"type\",\n]\nparams = [\"availability\", \"maintainer\", \"category\", \"type\"]\n\n# \"Highlighted Samples\" section on the main page\n[[params.samples]]\ntitle = \"RabbitMQ and Go\"\ncontent = \"RabbitMQ Consumer written in Go that is scaled with KEDA.\"\nurl = \"https://github.com/kedacore/sample-go-rabbitmq\"\nicon = \"fas fa-envelope\"\n\n[[params.samples]]\ntitle = \"Azure Functions and Queue\"\ncontent = \"Azure Function that triggers on Azure Storage Queues.\"\nurl = \"https://github.com/kedacore/sample-hello-world-azure-functions\"\nicon = \"fas fa-bolt\"\n\n[[params.samples]]\ntitle = \".NET Core worker and Azure Service Bus\"\ncontent = \"Scale a .NET Core worker based on an Azure Service Bus queue.\"\nurl = \"https://github.com/kedacore/sample-dotnet-worker-servicebus-queue\"\nicon = \"fas fa-cloud\"\n\n# Social media buttons\n[[params.social]]\nname = \"Twitter\"\nicon = \"fab fa-twitter\"\nbg_color = \"twitter-blue\"\nicon_color = \"white\"\ntext_color = \"white\"\nurl = \"https://twitter.com/kedaorg\"\n\n[[params.social]]\nname = \"GitHub\"\nicon = \"fab fa-github\"\nbg_color = \"white\"\nicon_color = \"black\"\ntext_color = \"black\"\nurl = \"https://github.com/kedacore/keda\"\n\n[[params.social]]\nname = \"Slack\"\nicon = \"fab fa-slack\"\nbg_color = \"slack-green\"\nicon_color = \"white\"\ntext_color = \"white\"\nurl = \"https://kubernetes.slack.com/messages/CKZJ36A5D\"\n\n# Main page hero buttons\n[[menu.buttons]]\nurl = \"/docs/concepts\"\nname = \"Concepts\"\npre = \"fas fa-bars-staggered\"\nweight = 1\n\n[[menu.buttons]]\nurl = \"/docs/deploy\"\nname = \"Deploying KEDA\"\npre = \"fas fa-circle-play\"\nweight = 2\n\n[[menu.buttons]]\nurl = \"/docs/concepts/#keda-architecture\"\nname = \"Architecture\"\npre = \"fas fa-diagram-project\"\nweight = 3\n\n[[menu.buttons]]\nurl = \"/docs/scalers\"\nname = \"Scalers\"\npre = \"fas fa-ruler-vertical\"\nweight = 4\n\n[[menu.buttons]]\nurl = \"/docs/authentication-providers\"\nname = \"Auth providers\"\npre = \"fas fa-lock\"\nweight = 5\n\n[[menu.buttons]]\nurl = \"/http-add-on/\"\nname = \"HTTP Add-on\"\npre = \"fas fa-globe\"\nweight = 6\n\n[[menu.buttons]]\nurl = \"/blog\"\nname = \"Blog\"\npre = \"fas fa-rss\"\nweight = 7\n\n# Navbar and footer menu\n[[menu.docs]]\nurl = \"/docs/\"\nname = \"Docs\"\nidentifier = \"docs\"\nweight = 1\n\n[[menu.docs]]\nurl = \"/docs/deploy\"\nname = \"Deploying KEDA\"\nparent = \"docs\"\nweight = 1\n\n[[menu.docs]]\nurl = \"/docs/concepts\"\nname = \"Concepts\"\nidentifier = \"Concepts\"\nparent = \"docs\"\nweight = 2\n\n[[menu.docs]]\nurl = \"/docs/concepts/scaling-deployments/\"\nname = \"Scaling Deployments, StatefulSets & Custom Resources\"\nparent = \"Concepts\"\nweight = 1\n\n[[menu.docs]]\nurl = \"/docs/concepts/scaling-jobs/\"\nname = \"Scaling Jobs\"\nparent = \"Concepts\"\nweight = 2\n\n[[menu.docs]]\nurl = \"/docs/concepts/authentication/\"\nname = \"Authentication\"\nparent = \"Concepts\"\nweight = 3\n\n[[menu.docs]]\nurl = \"/docs/concepts/external-scalers/\"\nname = \"External Scalers\"\nparent = \"Concepts\"\nweight = 4\n\n[[menu.docs]]\nurl = \"/docs/concepts/admission-webhooks/\"\nname = \"Admission Webhooks\"\nparent = \"Concepts\"\nweight = 5\n\n[[menu.docs]]\nurl = \"/docs/concepts/troubleshooting/\"\nname = \"Troubleshooting\"\nparent = \"Concepts\"\nweight = 6\n\n[[menu.docs]]\nurl = \"/docs/concepts/#keda-architecture\"\nname = \"Architecture\"\nparent = \"docs\"\nweight = 3\n\n[[menu.docs]]\nurl = \"/docs/scalers\"\nname = \"Scalers\"\nparent = \"docs\"\nweight = 4\n\n[[menu.docs]]\nurl = \"/docs/operate/\"\nname = \"Operate\"\nparent = \"docs\"\nweight = 5\n\n[[menu.docs]]\nurl = \"/docs/integrations/\"\nname = \"Integrations\"\nparent = \"docs\"\nweight = 6\n\n[[menu.docs]]\nurl = \"/docs/authentication-providers\"\nname = \"Auth providers\"\nparent = \"docs\"\nweight = 7\n\n[[menu.docs]]\nurl = \"/docs/migration/\"\nname = \"Migration Guide\"\nparent = \"docs\"\nweight = 8\n\n[[menu.docs]]\nurl = \"/docs/reference/faq/\"\nname = \"FAQ\"\nparent = \"docs\"\nweight = 9\n\n[[menu.docs]]\nurl = \"/docs/troubleshooting/\"\nname = \"Troubleshooting Guide\"\nparent = \"docs\"\nweight = 10\n\n[[menu.docs]]\nurl = \"/http-add-on/\"\nname = \"HTTP Add-on\"\nparent = \"docs\"\nweight = 11\n[menu.docs.params]\nprependDivider = true\n\n[[menu.main]]\nurl = \"/blog\"\nname = \"Blog\"\nweight = 2\n\n[[menu.main]]\nname = \"Community\"\nidentifier = \"community\"\nweight = 3\n\n[[menu.main]]\nurl = \"/community/\"\nname = \"Overview\"\nparent = \"community\"\nweight = 1\n\n[[menu.main]]\nurl = \"/community/#get-involved\"\nname = \"Get Involved\"\nparent = \"community\"\nweight = 2\n\n[[menu.main]]\nurl = \"/community/#end-users\"\nname = \"End-Users\"\nparent = \"community\"\nweight = 3\n\n[[menu.main]]\nurl = \"/community/#partners\"\nname = \"Partners\"\nparent = \"community\"\nweight = 4\n\n[[menu.main]]\nurl = \"/community/#supported-by\"\nname = \"Supported by\"\nparent = \"community\"\nweight = 5\n\n[[menu.main]]\nurl = \"/videos/\"\nname = \"Videos\"\nparent = \"community\"\nweight = 6\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/samples\"\nname = \"Samples\"\nparent = \"community\"\nweight = 7\n\n[[menu.main]]\nname = \"Project\"\nidentifier = \"project\"\nweight = 4\n\n[[menu.main]]\nurl = \"/support/\"\nname = \"Support\"\nparent = \"project\"\nweight = 1\n\n[[menu.main]]\nurl = \"https://github.com/cncf/foundation/blob/master/code-of-conduct.md\"\nname = \"Code of Conduct\"\nparent = \"project\"\nweight = 2\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/keda/blob/main/CHANGELOG.md\"\nname = \"Changelog\"\nparent = \"project\"\nweight = 3\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/governance/blob/main/GOVERNANCE.md\"\nname = \"Governance\"\nparent = \"project\"\nweight = 4\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/keda/blob/main/ROADMAP.md\"\nname = \"Roadmap\"\nparent = \"project\"\nweight = 5\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md\"\nname = \"Breaking Changes & Deprecations\"\nparent = \"project\"\nweight = 6\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md\"\nname = \"Contributing\"\nparent = \"project\"\nweight = 7\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/governance/blob/main/BRANDING.md\"\nname = \"Colors and Logos\"\nparent = \"project\"\nweight = 8\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/keda/blob/main/LICENSE\"\nname = \"License\"\nparent = \"project\"\nweight = 9\n\n[[menu.main]]\nurl = \"https://github.com/kedacore/governance/blob/main/MEMBERS.md\"\nname = \"Maintainers\"\nparent = \"project\"\nweight = 10\n\n[[menu.main]]\nurl = \"/resources/\"\nname = \"Learning Resources\"\nparent = \"project\"\nweight = 11\n\n[[menu.main]]\nurl = \"https://store.cncf.io/collections/keda\"\nname = \"Merch\"\nparent = \"project\"\nweight = 12\n\n[[menu.main]]\nurl = \"/enterprise/\"\nname = \"Enterprise\"\nweight = 5\n\n# \"Features\" section on the main page\n[[params.features]]\ntitle = \"Autoscaling Made Simple\"\ncontent = \"Bring rich scaling to every workload in your [Kubernetes](https://kubernetes.io) cluster\"\nicon = \"fas fa-rocket\"\n\n[[params.features]]\ntitle = \"Event-driven\"\ncontent = \"Intelligently scale your event-driven application\"\nicon = \"fas fa-bolt\"\n\n[[params.features]]\ntitle = \"Built-in Scalers\"\ncontent = \"Catalog of 70+ built-in scalers for various cloud platforms, databases, messaging systems, telemetry systems, CI/CD, and more\"\nicon = \"fas fa-cubes\"\n\n[[params.features]]\ntitle = \"Multiple Workload Types\"\ncontent = \"Support for variety of workload types such as deployments, jobs & custom resources with `/scale` sub-resource\"\nicon = \"fas fa-shapes\"\n\n[[params.features]]\ntitle = \"Reduce environmental impact\"\ncontent = \"Build sustainable platforms by optimizing workload scheduling and scale-to-zero\"\nicon = \"fas fa-seedling\"\n\n[[params.features]]\ntitle = \"Extensible\"\ncontent = \"Bring-your-own or use community-maintained scalers\"\nicon = \"fas fa-diagram-project\"\n\n[[params.features]]\ntitle = \"Vendor-Agnostic\"\ncontent = \"Support for triggers across variety of cloud providers & products\"\nicon = \"fas fa-cloud\"\n\n[[params.features]]\ntitle = \"Azure Functions Support\"\ncontent = \"Run and scale your Azure Functions on Kubernetes in production workloads\"\nicon = \"fab fa-microsoft\"\n\n# \"Users\" section on the Community page\n[[params.users]]\nurl = \"https://alibabacloud.com/\"\nlogo = \"alibaba-cloud.png\"\n\n[[params.users]]\nurl = \"https://ampify.io/\"\nlogo = \"ampify-io.png\"\n\n[[params.users]]\nurl = \"https://airflow.apache.org/\"\nlogo = \"apache-airflow.png\"\n\n[[params.users]]\nurl = \"https://www.astronomer.io\"\nlogo = \"astronomer.svg\"\n\n[[params.users]]\nurl = \"https://baseten.co/\"\nlogo = \"baseten.png\"\n\n[[params.users]]\nurl = \"https://www.bolddesk.com/\"\nlogo = \"bolddesk.svg\"\n\n[[params.users]]\nurl = \"https://chattermill.com\"\nlogo = \"chattermill.png\"\n\n[[params.users]]\nurl = \"https://cap.energy\"\nlogo = \"capenergy.png\"\n\n[[params.users]]\nurl = \"https://cisco.com\"\nlogo = \"cisco.svg\"\n\n[[params.users]]\nurl = \"https://www.cloud-trade.com\"\nlogo = \"cloud-trade.png\"\n\n[[params.users]]\nurl = \"https://coralogix.com/\"\nlogo = \"coralogix.gif\"\n\n[[params.users]]\nurl = \"https://cyera.io\"\nlogo = \"cyera.png\"\n\n[[params.users]]\nurl = \"https://devtron.ai\"\nlogo = \"devtron-logo.png\"\n\n[[params.users]]\nurl = \"https://dig.security\"\nlogo = \"digsecurity.gif\"\n\n[[params.users]]\nurl = \"https://docplanner.tech\"\nlogo = \"docplanner-tech.png\"\n\n[[params.users]]\nurl = \"https://www.fedex.com/en-us/home.html/\"\nlogo = \"fedex.png\"\n\n[[params.users]]\nurl = \"https://fission.io/\"\nlogo = \"fission.png\"\n\n[[params.users]]\nurl = \"https://www.foresightmining.com/\"\nlogo = \"foresight.png\"\n\n[[params.users]]\nurl = \"https://www.freepikcompany.com/\"\nlogo = \"freepik-company.png\"\n\n[[params.users]]\nurl = \"https://www.grafana.com\"\nlogo = \"grafana.png\"\n\n[[params.users]]\nurl = \"https://www.grab.com\"\nlogo = \"grab.svg\"\n\n[[params.users]]\nurl = \"https://github.com/hmcts/\"\nlogo = \"hmcts.png\"\n\n[[params.users]]\nurl = \"https://intension.de\"\nlogo = \"intension.png\"\n\n[[params.users]]\nurl = \"https://www.intercept.cloud\"\nlogo = \"intercept.png\"\n\n[[params.users]]\nurl = \"https://kaufland-ecommerce.com\"\nlogo = \"kaufland-ecommerce.png\"\n\n[[params.users]]\nurl = \"https://kendaxa.com\"\nlogo = \"kendaxa.png\"\n\n[[params.users]]\nurl = \"https://home.kpmg/uk/en/home.html\"\nlogo = \"KPMG.jpeg\"\n\n[[params.users]]\nurl = \"https://www.leanix.net/\"\nlogo = \"leanix.png\"\n\n[[params.users]]\nurl = \"https://maus.technology/\"\nlogo = \"maus-technology.png\"\n\n[[params.users]]\nurl = \"https://underthehood.meltwater.com/\"\nlogo = \"meltwater.png\"\n\n[[params.users]]\nurl = \"https://metamaze.eu/\"\nlogo = \"metamaze.png\"\n\n[[params.users]]\nurl = \"https://microsoft.com\"\nlogo = \"microsoft.png\"\n\n[[params.users]]\nurl = \"https://www.mivation.com\"\nlogo = \"mivation-inc.png\"\n\n[[params.users]]\nurl = \"https://nemlig.com\"\nlogo = \"nemlig.png\"\n\n[[params.users]]\nurl = \"https://opsworks.co\"\nlogo = \"opsworks.png\"\n\n[[params.users]]\nurl = \"https://www.playstudios.com\"\nlogo = \"playstudios.jpg\"\n\n[[params.users]]\nurl = \"https://www.pollinate.global\"\nlogo = \"pollinate.gif\"\n\n[[params.users]]\nurl = \"https://www.procore.com\"\nlogo = \"procore.svg\"\n\n[[params.users]]\nurl = \"https://www.theproindia.com\"\nlogo = \"pro-logo.svg\"\n\n[[params.users]]\nurl = \"https://www.purefacts.com\"\nlogo = \"purefacts.png\"\n\n[[params.users]]\nurl = \"https://qonto.com\"\nlogo = \"qonto.png\"\n\n[[params.users]]\nurl = \"https://redhat.com\"\nlogo = \"red-hat.png\"\n\n[[params.users]]\nurl = \"https://www.reddit.com/\"\nlogo = \"reddit.svg\"\n\n[[params.users]]\nurl = \"https://www.rewe-digital.com/\"\nlogo = \"rewe-digital.svg\"\n\n[[params.users]]\nurl = \"https://roadwork.io\"\nlogo = \"roadwork.png\"\n\n[[params.users]]\nurl = \"https://www.schrederhyperion.com\"\nlogo = \"schreder-hyperion.png\"\n\n[[params.users]]\nurl = \"https://schwarz-digits.de/en\"\nlogo = \"schwarz-digits.png\"\n\n[[params.users]]\nurl = \"https://seldon.io/\"\nlogo = \"seldon.png\"\n\n[[params.users]]\nurl = \"https://sharry.tech/\"\nlogo = \"sharry.png\"\n\n[[params.users]]\nurl = \"https://stilingue.com.br\"\nlogo = \"stilingue.png\"\n\n[[params.users]]\nurl = \"https://www.swisslife.ch/\"\nlogo = \"swisslife.jpg\"\n\n[[params.users]]\nurl = \"https://www.taotesting.com\"\nlogo = \"taotesting.svg\"\n\n[[params.users]]\nurl = \"https://www.teamleader.eu\"\nlogo = \"teamleader.png\"\n\n[[params.users]]\nurl = \"https://www.unitary.ai/\"\nlogo = \"unitary.png\"\n\n[[params.users]]\nurl = \"https://vitc.gmbh\"\nlogo = \"vitc.png\"\n\n[[params.users]]\nurl = \"https://www.wakacje.pl/\"\nlogo = \"wakacje.png\"\n\n[[params.users]]\nurl = \"https://www.wingie.com\"\nlogo = \"wingie-enuygun.png\"\n\n[[params.users]]\nurl = \"https://www.workiva.com\"\nlogo = \"workiva.png\"\n\n[[params.users]]\nurl = \"https://www.xbox.com\"\nlogo = \"xbox.png\"\n\n[[params.users]]\nurl = \"https://zapier.com\"\nlogo = \"zapier.png\"\n\n\n# \"Partners\" section on the Community page\n[[params.partners]]\nurl = \"https://kedify.io/?utm_source=keda_oss_site\"\nlogo = \"kedify.png\"\n\n[[params.partners]]\nurl = \"https://schwarz-digits.de/en\"\nlogo = \"schwarz-digits.png\"\n\n# \"Supported by\" section on the Community page\n[[params.supportedby]]\nurl = \"https://azure.microsoft.com/en-us/services/devops/\"\nlogo = \"azure-devops.png\"\n\n[[params.supportedby]]\nurl = \"https://www.cncf.io/\"\nlogo = \"cncf-color.png\"\n\n[[params.supportedby]]\nurl = \"https://azure.microsoft.com/\"\nlogo = \"microsoft-azure.png\"\n\n[[params.supportedby]]\nurl = \"https://snyk.io\"\nlogo = \"snyk.png\"\n\n[[params.supportedby]]\nurl = \"https://vexxhost.com\"\nlogo = \"vexxhost.png\"\n\n# Enterprise page, sorted alphabetically by name of the vendor\n[[params.vendors]]\nname = \"Kedify\"\nlogo = \"vendors/kedify.png\"\ndescription = \"\"\"\nKedify is founded by the core maintainers of KEDA and offers enterprise autoscaling solutions based on KEDA, providing:\n- State-of-the-art scalers and features, including a **production-grade HTTP Scaler**, exclusively available in Kedify.\n- Support for Multi-tenant KEDA installation, Multi-Cluster scaling, Predictive and Vertical scaling, and more.\n- **Enterprise-grade support**, ensuring secure KEDA builds with timely updates, patches, and critical fixes.\n- A comprehensive **dashboard** for streamlined management and monitoring across multiple clusters.\n\"\"\"\nurls = [\n  { text = \"Visit Kedify website for more details\", url = \"https://kedify.io/?utm_source=keda_oss_site\" },\n]\n\n[[params.vendors]]\nname = \"Microsoft\"\nlogo = \"vendors/microsoft-azure.png\"\ndescription = \"\"\"\nMicrosoft provides multiple solutions integrated with KEDA:\n- **Azure Container Apps**: Allows you to deploy microservices that automatically scale based on KEDA.\n- **KEDA Add-On for Azure Kubernetes Service**: Plugin for straightforward installation on Azure Kubernetes Service.\n\"\"\"\nurls = [\n  { text = \"Azure Container Apps\", url = \"https://docs.microsoft.com/en-us/azure/container-apps/scale-app\" },\n  { text = \"AKS KEDA Add-On\", url = \"https://docs.microsoft.com/en-us/azure/aks/keda-about\" },\n]\n\n[[params.vendors]]\nname = \"Red Hat\"\nlogo = \"vendors/red-hat.png\"\ndescription = \"\"\"\nRed Hat integrates KEDA with OpenShift through the **Custom Metrics Autoscaler** (CMA) available through the OpenShift Marketplace.\n\"\"\"\nurls = [\n  { text = \"Learn more about the CMA\", url = \"https://cloud.redhat.com/blog/custom-metrics-autoscaler-on-openshift\" },\n]\n\n[module]\n[[module.mounts]]\nsource = \"static\"\ntarget = \"static\"\n[[module.mounts]]\nsource = \"node_modules/@fortawesome/fontawesome-free/css\"\ntarget = \"static/fontawesome/css\"\n[[module.mounts]]\nsource = \"node_modules/@fortawesome/fontawesome-free/webfonts\"\ntarget = \"static/fontawesome/webfonts\"\n[[module.mounts]]\nsource = \"node_modules/@fontsource/inria-sans\"\ntarget = \"static/fonts/inria-sans\"\n[[module.mounts]]\nsource = \"node_modules/@fontsource/roboto-mono\"\ntarget = \"static/fonts/roboto-mono\"\n[[module.mounts]]\nsource = \"node_modules/@docsearch/css/dist\"\ntarget = \"static/css/docsearch\"\n"
  },
  {
    "path": "includes/get-involved.md",
    "content": "If you're interested in contributing to or participating in the direction of KEDA, you can join our community meetings.\n\n* Meeting time: Bi-weekly Tues 17:00 (European time - CEST/CET). (Subscribe to [Google Agenda](https://calendar.google.com/calendar?cid=bjE0bjJtNWM0MHVmam1ob2ExcTgwdXVkOThAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ) | [Convert to your timezone](https://dateful.com/time-zone-converter?t=04:00%20pm&tz=UTC))\n* Zoom link: https://zoom.us/j/96655859927?pwd=cGxaWWpHOVZSMEZDY3NuWWVIMERtdz09 (Password: keda)\n* Meeting agenda: [Google Docs](https://docs.google.com/document/d/1zdwD6j86GxcCe5S5ay9suCO77WPrEDnKSfuaI24EwM4/edit?usp=sharing)\n\nJust want to learn or chat about KEDA? Feel free to join the conversation in the [#keda](https://kubernetes.slack.com/messages/CKZJ36A5D) (general), [#keda-dev](https://kubernetes.slack.com/archives/C01JGDP8MB8) & [#keda-docs](https://kubernetes.slack.com/archives/C03M2DKCS3H) channel(s) on the [Kubernetes Slack](https://slack.k8s.io)!\n"
  },
  {
    "path": "layouts/404.html",
    "content": "{{ define \"title\" -}}\n404 Page not found | {{ site.Title -}}\n{{ end }}\n\n{{ define \"main\" -}}\n<section class=\"section\">\n    <div class=\"container\">\n      <div class=\"content is-medium is-constrained has-bottom-margin\">\n\n        <p class=\"title is-size-1 is-size-2-mobile has-text-weight-bold is-spaced\">\n            Woops! Page not found.\n          </p>\n\n        That's not very convenient, sorry about that!\n\n        Maybe you were looking for:\n        <ul>\n            <li><a href=\"{{ .Site.BaseURL }}/docs/latest/concepts\">An overview of our concepts</a></li>\n            <li><a href=\"{{ .Site.BaseURL }}/docs/latest/scalers\">A list of all our supported scalers</a></li>\n            <li><a href=\"{{ .Site.BaseURL }}/docs/latest/deploy\">How to deploy KEDA</a></li>\n            <li><a href=\"{{ .Site.BaseURL }}/docs/latest/operate\">How to operate KEDA</a></li>\n        </ul>\n\n\n        <article class=\"message is-info\">\n            <div class=\"message-header\">\n              <p class=\"is-size-5 is-size-6-mobile\">\n                Let us know\n              </p>\n            </div>\n            <div class=\"message-body\">\n              Let us know so we can fix this dead link, you can report it <a href=\"https://github.com/kedacore/keda-docs/issues/new\">here</a>.\n            </div>\n          </article></div>\n      </div>\n    </div>\n  </section>\n{{ end }}\n"
  },
  {
    "path": "layouts/_default/_markup/render-image.html",
    "content": "{{ $src := .Destination | safeURL }}\n{{ $id  := index (last 1 (split .Destination \"/\")) 0 | replaceRE \".png\" \"\" }}\n<figure x-data=\"{ open: false }\">\n  <img class=\"has-mouse-icon\" src=\"{{ $src }}\"{{ with .Text }} alt=\"{{ . }}\"{{ end }} id=\"{{ $id }}\" @click=\"open = true\">\n\n  <div class=\"modal\" id=\"modal-{{ $id }}\" :class=\"{ 'is-active': open }\">\n    <div class=\"modal-background\" @click=\"open = !open\"></div>\n    <div class=\"modal-content\">\n      <p class=\"image\">\n        <img src=\"{{ $src }}\"{{ with .Text }} alt=\"{{ . }}\"{{ end }}>\n      </p>\n    </div>\n\n    <button class=\"modal-close is-large\" aria-label=\"close\" @click=\"open = false\"></button>\n  </div>\n</figure>\n"
  },
  {
    "path": "layouts/_default/_markup/render-link.html",
    "content": "{{- $link := .Destination -}}\n{{ $isRemote := strings.HasPrefix $link \"http\" }}\n{{- if not $isRemote -}}\n{{ $url := urls.Parse .Destination }}\n{{- if $url.Path -}}\n{{- $fragment := \"\" -}}\n{{- with $url.Fragment }}{{ $fragment = printf \"#%s\" . }}{{ end -}}\n{{- if .Page.GetPage $url.Path }}{{ $link = printf \"%s%s\" (.Page.GetPage $url.Path).RelPermalink $fragment }}{{ end }}{{ end -}}\n{{- end -}}\n<a href=\"{{ $link | safeURL }}\"{{ with .Title }} title=\"{{ . }}\"{{ end }}{{ if $isRemote }} target=\"_blank\"{{ end }}>{{- .Text | safeHTML -}}{{ if $isRemote }}<sup><i class=\"fas fa-xs fa-up-right-from-square\"></i></sup>{{ end }}</a>"
  },
  {
    "path": "layouts/_default/baseof.html",
    "content": "<!DOCTYPE html>\n<html {{- with site.LanguageCode }} lang=\"{{ . }}\" {{- end }}>\n  <head>\n    {{ partial \"meta.html\" . }}\n    <title>\n      {{- block \"title\" . -}}\n        {{ .Title }} | {{ site.Title -}}\n      {{ end -}}\n    </title>\n    {{ partial \"css.html\" . }}\n    {{ partial \"favicon.html\" . }}\n  </head>\n  <body class=\"is-page has-navbar-fixed-top\">\n    <main class=\"is-main\">\n      {{ partial \"navbar.html\" . }}\n      {{ block \"main\" . }}{{ end }}\n    </main>\n    {{ partial \"footer.html\" . }}\n    {{ partial \"javascript.html\" . }}\n  </body>\n</html>\n"
  },
  {
    "path": "layouts/_default/card-info.html",
    "content": "{{ $desc         := .Description | markdownify }}\n{{ $availability := .Params.availability }}\n{{ $maintainer   := .Params.maintainer }}\n{{ $project   := .Params.project }}\n<div class=\"column is-one-third\">\n  <div class=\"card\">\n    <div class=\"card-content\">\n      <a class=\"title is-size-4 is-size-5-mobile has-text-primary has-text-weight-bold\" href=\"{{ .RelPermalink }}\">\n        {{ .Title }}\n      </a>\n\n      <br /><br />\n\n      {{ with $desc }}\n      <div class=\"content is-medium\">\n        {{ . }}\n      </div>\n      {{ end }}\n    </div>\n\n    {{ if or $availability $maintainer }}\n    <footer class=\"card-footer\">\n      {{ with $availability }}\n      <div class=\"card-footer-item is-spaced card-is-wrapped\">\n        Availability&nbsp;<span class=\"has-text-weight-bold\">{{ . }}</span>\n      </div>\n      {{ end }}\n\n      {{ with $maintainer }}\n      <div class=\"card-footer-item card-is-wrapped\">\n        Maintainer:&nbsp;<span class=\"has-text-weight-bold\">{{ . }}</span>\n      </div>\n      {{ end }}\n\n      {{ with $project }}\n      <div class=\"card-footer-item card-is-wrapped\">\n        Project:&nbsp;<span class=\"has-text-weight-bold\">{{ . }}</span>\n      </div>\n      {{ end }}\n    </footer>\n    {{ end }}\n  </div>\n</div>"
  },
  {
    "path": "layouts/_default/list.lunr.json",
    "content": "{{- $index := slice -}}\n{{- range $scalers := where site.RegularPages \".CurrentSection.Title\" \"Scalers\" -}}\n    {{- $index = $index | append (dict \"title\" $scalers.Title \"version\" (index (first 3 (split (delimit (split $scalers.RelPermalink \"/\") \",\" \"\") \",\")) 2) \"href\" $scalers.RelPermalink  \"availability\" $scalers.Params.availability \"description\" ($scalers.Params.description) \"maintainer\" $scalers.Params.maintainer \"category\" $scalers.Params.category \"type\" \"built-in\" ) -}}\n{{- end -}}\n\n{{- $index | jsonify -}}\n"
  },
  {
    "path": "layouts/_default/single.html",
    "content": "{{ define \"main\" }}\n{{ partial \"hero.html\" . }}\n{{ partial \"content.html\" . }}\n{{ end }}\n"
  },
  {
    "path": "layouts/_default/sitemap.xml",
    "content": "{{- /*  sitemap.xml should only contain canonical urls. */ -}}\n{{- /*  For versioned pages, the canonical is the current version and it's the only version we should include */ -}}\n{{- /*  For blog and other pages, we can include all of them as they aren't versioned */ -}}\n{{ $docsLatest := index site.Params.versions.docs 0 -}}\n{{ printf \"<?xml version=\\\"1.0\\\" encoding=\\\"utf-8\\\" standalone=\\\"yes\\\"?>\" | safeHTML }}\n<urlset xmlns=\"http://www.sitemaps.org/schemas/sitemap/0.9\"\n  xmlns:xhtml=\"http://www.w3.org/1999/xhtml\">\n  {{ range .Data.Pages }}\n    {{- if and \n        .Permalink\n        (or \n            (and (strings.Contains .Permalink \"docs/\") (strings.Contains .Permalink $docsLatest)) \n            (not (strings.Contains .Permalink \"docs/\"))\n        ) \n    -}}\n  <url>\n    <loc>{{ .Permalink }}</loc>{{ if not .Lastmod.IsZero }}\n    <lastmod>{{ safeHTML ( .Lastmod.Format \"2006-01-02T15:04:05-07:00\" ) }}</lastmod>{{ end }}{{ with .Sitemap.ChangeFreq }}\n    <changefreq>{{ . }}</changefreq>{{ end }}{{ if ge .Sitemap.Priority 0.0 }}\n    <priority>{{ .Sitemap.Priority }}</priority>{{ end }}{{ if .IsTranslated }}{{ range .Translations }}\n    <xhtml:link\n                rel=\"alternate\"\n                hreflang=\"{{ .Language.LanguageCode }}\"\n                href=\"{{ .Permalink }}\"\n                />{{ end }}\n    <xhtml:link\n                rel=\"alternate\"\n                hreflang=\"{{ .Language.LanguageCode }}\"\n                href=\"{{ .Permalink }}\"\n                />{{ end }}\n  </url>\n    {{- end -}}\n  {{ end }}\n</urlset>"
  },
  {
    "path": "layouts/blog/list.html",
    "content": "{{ define \"main\" -}}\n  {{ partial \"blog/list-hero.html\" . }}\n  {{ partial \"blog/posts.html\" . }}\n{{ end -}}\n"
  },
  {
    "path": "layouts/blog/single.html",
    "content": "{{ define \"main\" -}}\n{{ partial \"blog/post-hero.html\" . }}\n{{ partial \"blog/article.html\" . }}\n{{ end -}}\n"
  },
  {
    "path": "layouts/docs/list.html",
    "content": "{{ define \"main\" -}}\n  {{ partial \"article.html\" . }}\n{{ end -}}\n"
  },
  {
    "path": "layouts/docs/single.html",
    "content": "{{ define \"main\" -}}\n  {{ partial \"article.html\" . }}\n{{ end -}}\n"
  },
  {
    "path": "layouts/http-add-on/list.html",
    "content": "{{ define \"main\" -}}\n  {{ partial \"article.html\" . }}\n{{ end -}}\n"
  },
  {
    "path": "layouts/http-add-on/single.html",
    "content": "{{ define \"main\" -}}\n  {{ partial \"article.html\" . }}\n{{ end -}}\n"
  },
  {
    "path": "layouts/index.html",
    "content": "{{ define \"title\" -}}\n  {{ site.Title }} | {{ site.Params.tagline -}}\n{{ end }}\n\n{{ define \"main\" -}}\n  {{ partial \"home/hero.html\" . }}\n  {{ partial \"home/what-is.html\" . }}\n  {{ partial \"home/features.html\" . }}\n  {{ partial \"home/video.html\" . }}\n  {{ partial \"home/scalers.html\" . }}\n  {{ partial \"home/samples.html\" . }}\n  {{ partial \"logo-section.html\" (dict \"title\" \"Users\" \"description\" \"A variety of users are autoscaling applications with KEDA:\" \"logos\" site.Params.users) }}\n  <hr />\n  {{ partial \"logo-section.html\" (dict \"title\" \"Partners\" \"description\" \"KEDA is supported by and built by our community, including the following companies:\" \"logos\" site.Params.partners) }}\n  <hr />\n  {{ partial \"logo-section.html\" (dict \"title\" \"Supported by\" \"description\" \"KEDA is supported by the following companies that provide their services for free:\" \"logos\" site.Params.supportedby) }}\n\n  {{ partial \"home/get-involved.html\" . }}\n  {{ partial \"home/cncf.html\" . }}\n\n  <img referrerpolicy=\"no-referrer-when-downgrade\" src=\"https://static.scarf.sh/a.png?x-pxid=46ce89e3-f6ce-454e-9740-490aaee3da5e\" />\n{{ end -}}\n"
  },
  {
    "path": "layouts/index.redirects",
    "content": "{{ $docsLatest := index site.Params.versions.docs 0 -}}\n{{ $httpAddonLatest := index (index site.Params.versions \"http-add-on\") 0 -}}\n\n/docs            /docs/{{ $docsLatest }}     302\n/docs/latest/*   /docs/{{ $docsLatest }}/:splat     302\n\n{{ $topLevel := slice \"scalers\" \"faq\" \"troubleshooting\" \"operate\" \"concepts\" \"deploy\" -}}\n{{ range $name := $topLevel -}}\n{{ $docp := printf \"docs/%s/*\" $name -}}\n{{ $name | printf \"/%-29s\" }}  /docs/{{ $docsLatest }}/{{ $name }}     301!\n{{ $docp | printf \"/%-29s\" }}  /docs/{{ $docsLatest }}/{{ $name }}/:splat\n{{ end -}}\n\n/http-add-on             /http-add-on/{{ $httpAddonLatest }}     302\n/http-add-on/latest/*    /http-add-on/{{ $httpAddonLatest }}/:splat     302\n\n{{ $scalers    := where site.RegularPages \"Section\" \"scalers\" -}}\n{{- range $scalers -}}\n{{- $path := index (split .RelPermalink \"/\") 2 }}\n/docs/scalers/{{ $path }}     /scalers/{{ $path }}\n{{- end -}}\n"
  },
  {
    "path": "layouts/partials/article.html",
    "content": "<div class=\"container section\">\n  <div class=\"columns is-variable is-8-desktop is-0-touch\">\n    <div class=\"column is-one-quarter-desktop is-hidden-touch\">\n      {{ partial \"nav.html\" . }}\n    </div>\n\n    <div class=\"column is-three-quarters-desktop is-content-column\">\n      {{ partial \"docs/hero.html\" . }}\n      {{ partial \"content.html\" . }}\n    </div>\n  </div>\n</div>"
  },
  {
    "path": "layouts/partials/blog/article.html",
    "content": "{{ $posts := where site.RegularPages \"Section\" \"blog\" }}\n\n<section class=\"container section\">\n  <div class=\"columns is-variable is-desktop\">\n    <div class=\"column is-8-desktop\">\n      <div class=\"content is-medium has-bottom-margin\">\n        {{ .Content | replaceRE \"(<h[2-9] id=\\\"([^\\\"]+)\\\".+)(</h[2-9]+>)\" `${1} <a class=\"headline-hash\" href=\"#${2}\"><span class=\"icon hashlink\"><i class=\"fas fa-hashtag\"></i></span></a>${3}` | safeHTML }}\n      </div>\n\n      {{ partial \"blog/pagination.html\" . }}\n    </div>\n\n    <div class=\"column is-4-desktop\">\n      <div class=\"is-sticky\">\n        <p class=\"title is-size-3 is-size-4-mobile\">\n          Recent posts\n        </p>\n\n        {{ range $posts }}\n        <a class=\"is-size-4 is-size-5-mobile\" href=\"{{ .RelPermalink }}\">\n          {{ .Title }}\n        </a>\n        <br />\n        {{ end }}\n\n        <br />\n\n        {{ partial \"blog/rss-button.html\" . }}\n      </div>\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/blog/list-hero.html",
    "content": "{{ $title := .Title }}\n{{ $desc  := .Description }}\n<section class=\"hero is-dark is-medium has-background-pattern\">\n  <div class=\"hero-body\">\n    <div class=\"container\">\n      <p class=\"title is-size-1 is-size-2-mobile has-text-weight-bold is-spaced has-shadow\">\n        {{ .Title }}\n      </p>\n\n      <p class=\"subtitle is-size-3 is-size-4-mobile has-text-weight-bold has-shadow\">\n        {{ $desc }}\n      </p>\n\n      {{ partial \"blog/rss-button.html\" . }}\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/blog/pagination.html",
    "content": "<nav class=\"pagination\" role=\"navigation\" aria-label=\"pagination\">\n  {{ with .PrevInSection }}\n  <a class=\"pagination-next button is-primary is-outlined\" href=\"{{ .RelPermalink }}\">\n    <span class=\"icon\">\n      <i class=\"fas fa-chevron-left\"></i>\n    </span>\n    <span>\n      Previous:&nbsp;<strong>{{ .Title }}</strong>\n    </span>\n  </a>\n  {{ end }}\n\n  {{ with .NextInSection }}\n  <a class=\"pagination-next button is-primary is-outlined\" href=\"{{ .RelPermalink }}\">\n    <span>\n      Next:&nbsp;<strong>{{ .Title }}</strong>\n    </span>\n    <span class=\"icon\">\n      <i class=\"fas fa-chevron-right\"></i>\n    </span>\n  </a>\n  {{ end }}\n\n  <div class=\"pagination-list\">\n    <a class=\"pagination-link button is-primary\" href=\"/blog\">\n      <span class=\"icon\">\n        <i class=\"fas fa-arrow-left\"></i>\n      </span>\n      <span>\n        Back to blog\n      </span>\n    </a>\n  </div>\n</nav>"
  },
  {
    "path": "layouts/partials/blog/post-hero.html",
    "content": "{{ $title  := .Title }}\n{{ $author := .Params.author }}\n{{ $date   := dateFormat \"January 2, 2006\" .Date }}\n\n{{ if not $title }}\n{{ errorf \"no title specified in the post you created in content/%s\" .File.Path }}\n{{ end }}\n\n{{ if not $date }}\n{{ errorf \"no date specified in the post you created in content/%s\" .File.Path }}\n{{ end }}\n\n{{ if not $author }}\n{{ errorf \"no author specified in the post you created in content/%s\" .File.Path }}\n{{ end }}\n\n<span class=\"docsearch-lvl0\" hidden>Blog</span>\n<section class=\"hero is-dark is-medium has-background-pattern\">\n  <div class=\"hero-body\">\n    <div class=\"container\">\n      <p class=\"title is-size-1 is-size-2-mobile has-text-weight-bold is-spaced\">\n        <span class=\"title-text\">{{ $title }}</span>\n      </p>\n\n      <p class=\"subtitle is-size-2 is-size-3-mobile\">\n        {{ $author }}\n      </p>\n\n      <p class=\"subtitle is-size-4 is-size-5-mobile\">\n        {{ $date }}\n      </p>\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/blog/posts.html",
    "content": "{{ $posts := where site.RegularPages \"Section\" \"blog\" }}\n<section class=\"section\">\n  <div class=\"container\">\n    <div class=\"columns is-multiline\">\n      {{ range $posts }}\n      {{ $title  := .Title }}\n      {{ $url    := .RelPermalink }}\n      {{ $author := .Params.author }}\n      {{ $date   := dateFormat \"January 2, 2006\" .Date }}\n      <div class=\"column is-half\">\n        <div class=\"card\">\n          <div class=\"card-content\">\n            <p class=\"title has-text-weight-bold is-spaced\">\n              <a href=\"{{ $url }}\">\n                {{ $title }}\n              </a>\n            </p>\n\n            {{ with $author }}\n            <p class=\"subtitle is-size-4 is-size-5-mobile has-text-weight-bold\">\n              {{ . }}\n            </p>\n            {{ end }}\n\n            <p class=\"subtitle is-size-5 is-size-6-mobile has-text-grey\">\n              {{ $date }}\n            </p>\n\n            {{ with .Summary }}\n            <p class=\"content is-medium\">\n              {{ . }}\n            </p>\n            {{ end }}\n          </div>\n        </div>\n      </div>\n      {{ end }}\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/blog/rss-button.html",
    "content": "{{ $rss   := .CurrentSection.OutputFormats.Get \"rss\" }}\n<div class=\"buttons hero-buttons\">\n  <a class=\"button is-orange\" href=\"{{ $rss.RelPermalink }}\">\n    <span class=\"icon\">\n      <i class=\"fas fa-rss\"></i>\n    </span>\n    <span class=\"has-text-weight-bold\">\n      RSS\n    </span>\n  </a>\n</div>"
  },
  {
    "path": "layouts/partials/content.html",
    "content": "{{ $notice   := .Params.notice }}\n{{ $isScaler := eq .CurrentSection.Title \"Scalers\" }}\n{{ $index := eq .File.LogicalName \"_index.md\"}}\n<section>\n  <div class=\"content is-medium is-constrained has-bottom-margin\">\n    {{ with $notice }}\n    <article class=\"message is-warning\">\n      <div class=\"message-header\">\n        <p class=\"is-size-5 is-size-6-mobile\">\n          Notice\n        </p>\n      </div>\n      <div class=\"message-body\">\n        {{ . }}\n      </div>\n    </article>\n    {{ end }}\n\n    {{ .Content | replaceRE \"(<h[2-9] id=\\\"([^\\\"]+)\\\".+)(</h[2-9]+>)\" `${1} <a class=\"headline-hash\" href=\"#${2}\"><span class=\"icon hashlink\"><i class=\"fas fa-hashtag\"></i></span></a>${3}` | safeHTML }}\n\n    {{ if and ($isScaler) ($index) }}\n    {{ partial \"scaler-layout\" . }}\n    {{ end }}\n  </div>\n</section>\n\n"
  },
  {
    "path": "layouts/partials/css.html",
    "content": "{{ $inDevMode    := not hugo.IsProduction -}}\n{{ $includePaths := (slice \"node_modules\") -}}\n{{ $sass         := \"sass/style.sass\" -}}\n{{ $cssOutput    := \"css/style.css\" -}}\n{{ $devOpts      := (dict \"targetPath\" $cssOutput \"includePaths\" $includePaths \"enableSourceMap\" true) -}}\n{{ $prodOpts     := (dict \"targetPath\" $cssOutput \"includePaths\" $includePaths \"outputStyle\" \"compressed\") -}}\n{{ $cssOpts      := cond $inDevMode $devOpts $prodOpts -}}\n{{ $css          := resources.Get $sass | resources.ExecuteAsTemplate $sass . | css.Sass $cssOpts -}}\n{{ if $inDevMode -}}\n  <link rel=\"stylesheet\" href=\"{{ $css.RelPermalink }}\">\n{{ else -}}\n  {{ $prodCss := $css | fingerprint -}}\n  <link rel=\"stylesheet\" href=\"{{ $prodCss.RelPermalink }}\" integrity=\"{{ $prodCss.Data.Integrity }}\">\n{{ end -}}\n{{ range site.Params.fonts -}}\n{{ $fontFile := replace (lower .name) \" \" \"-\" -}}\n{{ range .sizes -}}\n<link rel=\"stylesheet\" href=\"/fonts/{{ $fontFile }}/latin-{{ . }}.css\" />\n{{ end -}}\n{{ end -}}\n<link rel=\"stylesheet\" href=\"/fontawesome/css/all.min.css\" />\n<link rel=\"stylesheet\" href=\"/css/docsearch/style.css\" />\n"
  },
  {
    "path": "layouts/partials/doc-version-selector.html",
    "content": "{{ $releasedVersions   := index site.Params.versions .Section }}\n{{ $unreleasedVersions := default slice (index site.Params.unreleased .Section) }}\n{{ $allVersions        := $unreleasedVersions | append $releasedVersions }}\n{{ $latest             := index $releasedVersions 0 }}\n{{ $version            := \"\" }}\n{{ with .File }}{{ $version = index (split .Path \"/\") 1 }}{{ end }}\n{{ $isLatest           := eq $latest $version }}\n{{ $isUnreleased       := in $unreleasedVersions $version }}\n{{ $versionsOfDoc      := slice }}\n{{ $here               := (delimit (after 3 (split (delimit (split .RelPermalink \"/\") \",\" \"\") \",\")) \"/\") }}\n{{ $path               := \"\" }}\n{{ with .File }}{{ $path = .Path }}{{ end }}\n{{ $section            := .Section }}\n{{ range $allVersions }}\n{{ $fileToCheck := replace $path $version . }}\n{{ if fileExists $fileToCheck }}\n{{ $versionsOfDoc = $versionsOfDoc | append . }}\n{{ end }}\n{{ end }}\n{{ $onlyOne     := eq (len $versionsOfDoc) 1 }}\n<div class=\"dropdown\" x-data=\"{ open: false }\" :class=\"{ 'is-active': open }\">\n  <div class=\"dropdown-trigger\">\n    <button class=\"button is-black\" aria-haspopup=\"true\" aria-controls=\"dropdown-menu\" @click=\"open = !open\" @click.outside=\"open = false\">\n      Version\n      &nbsp;\n      <span class=\"has-text-weight-bold\">\n        {{ $version }}\n      </span>\n      {{ if $isUnreleased }}\n      &nbsp;\n      <span>\n        (unreleased)\n      </span>\n      {{ else if $isLatest }}\n      &nbsp;\n      <span>\n        (latest)\n      </span>\n      {{ end }}\n      {{ if not $onlyOne }}\n      <span class=\"icon is-small has-text-primary\">\n        <i class=\"fas fa-angle-down\" aria-hidden=\"true\"></i>\n      </span>\n      {{ end }}\n    </button>\n  </div>\n  {{ if not $onlyOne }}\n  <div class=\"dropdown-menu\" id=\"dropdown-menu\" role=\"menu\">\n    <div class=\"dropdown-content\">\n      {{ range $versionsOfDoc }}\n      {{ $isLatest := eq . $latest }}\n      {{ $isUnreleased := in $unreleasedVersions . }}\n      <a class=\"dropdown-item\" href=\"/{{ $section }}/{{ . }}/{{ $here }}\">\n        <span>\n          {{ . }}\n        </span>\n        {{ if $isUnreleased }}\n        &nbsp;\n        <span>\n          (unreleased)\n        </span>\n        {{ else if $isLatest }}\n        &nbsp;\n        <span>\n          (latest)\n        </span>\n        {{ end }}\n      </a>\n      {{ end }}\n    </div>\n  </div>\n  {{ end }}\n</div>\n"
  },
  {
    "path": "layouts/partials/docs/hero.html",
    "content": "{{ $title         := .Title }}\n{{ $desc          := .Description }}\n{{ $src           := printf \"https://github.com/kedacore/keda-docs/blob/main/content/%s\" .File.Path }}\n{{ $availability  := .Params.availability }}\n{{ $maintainer    := .Params.maintainer }}\n{{ $isScaler      := eq .CurrentSection.Title \"Scalers\" }}\n{{ $isSectionRoot := eq .File.BaseFileName \"_index\" }}\n{{ $version       := index (split .File.Path \"/\") 1 }}\n{{ $latest        := index (index site.Params.versions .Section) 0 }}\n{{ $isLatest      := eq $version $latest }}\n{{ $isNextVersion := not (in (index site.Params.versions .Section) $version) }}\n{{ $productNames  := dict \"docs\" \"KEDA\" \"http-add-on\" \"HTTP Add-on\" }}\n{{ $productName   := index $productNames .Section }}\n\n<!-- Check if latest version of this page exists -->\n{{ $latestUrl := replaceRE $version $latest .RelPermalink }}\n{{ $latestPageExists := false }}\n{{ range site.Pages }}\n  {{ if eq .RelPermalink $latestUrl }}\n    {{ $latestPageExists = true }}\n  {{ end }}\n{{ end }}\n\n<span class=\"docsearch-lvl0\" hidden>{{ $productName }} v{{ $version }}</span>\n<section class=\"doc-hero\">\n  <p class=\"title is-size-1 is-size-2-mobile has-text-weight-bold{{ if $desc }} is-spaced{{ end }}\">\n    <span class=\"title-text\">{{ $title }}</span>\n    <sup>\n      {{ if $isLatest }}\n      <span class=\"tag is-success\">Latest</span>\n      {{ else if and (not $isNextVersion) $latestPageExists }}\n      <a href=\"{{ $latestUrl }}\">\n        <span class=\"tag is-warning\">Click here for latest</span>\n      </a>\n      {{ end }}\n    </sup>\n  </p>\n\n  {{ with $desc }}\n  <p class=\"subtitle\">\n    {{ . }}\n  </p>\n  {{ end }}\n\n  {{ if or $availability $maintainer (and $isScaler (not $isSectionRoot)) }}\n  <div class=\"field\">\n    <p class=\"control\">\n      <div class=\"tags are-medium\">\n        {{ with $availability }}\n        <span class=\"tag\">\n          Availability:&nbsp;<span class=\"has-text-weight-bold\">{{ . }}</span>\n        </span>\n        {{ end }}\n\n        {{ with $maintainer }}\n        <span class=\"tag is-outlined\">\n          Maintainer:&nbsp;<span class=\"has-text-weight-bold\">{{ . }}</span>\n        </span>\n        {{ end }}\n\n        {{ if and $isScaler (not $isSectionRoot) }}\n        {{ $url := printf \"https://github.com/kedacore/keda/blob/main/pkg/scalers/%s.go\" .Params.go_file }}\n        <div class=\"tag is-black\">\n          <span class=\"icon\">\n            <i class=\"fab fa-github\"></i>\n          </span>\n          <a class=\"has-text-light\" href=\"{{ $url }}\" target=\"_blank\">\n            Scaler code\n          </a>\n        </div>\n        {{ end }}\n      </div>\n    </p>\n  </div>\n  {{ end }}\n\n  <div class=\"buttons are-small are-spaced\">\n    {{ partial \"doc-version-selector.html\" . }}\n\n    <a class=\"button is-dark is-outlined\" href=\"{{ $src }}\" target=\"_blank\">\n      <span class=\"icon\">\n        <i class=\"fab fa-github\"></i>\n      </span>\n      <span>\n        Suggest a change\n      </span>\n    </a>\n  </div>\n\n  {{ if and (not $isLatest) $latestPageExists }}\n  <article class=\"message is-warning\">\n    <div class=\"message-header\">\n      <p>Warning</p>\n    </div>\n    <div class=\"message-body\">\n      You are currently viewing v{{ $version }} of the documentation and it is not the latest. For the most recent documentation, kindly <a href=\"{{ $latestUrl }}\"> click here.</a>\n    </div>\n  </article>\n  {{ else if and (not $isLatest) (not $isNextVersion) }}\n  <article class=\"message is-info\">\n    <div class=\"message-header\">\n      <p>Notice</p>\n    </div>\n    <div class=\"message-body\">\n      This page does not exist in the latest version ({{ $latest }}). It may have been deprecated or replaced. Check the <a href=\"/{{ .Section }}/{{ $latest }}/\">{{ $latest }} documentation</a> for alternatives.\n    </div>\n  </article>\n  {{ end }}\n</section>\n"
  },
  {
    "path": "layouts/partials/favicon.html",
    "content": "{{ $favicon := site.Params.favicon | absURL }}\n{{ with $favicon }}\n{{ $url := . | relURL }}\n<link rel=\"shortcut icon\" href=\"{{ $url }}\">\n{{ end }}\n"
  },
  {
    "path": "layouts/partials/footer.html",
    "content": "{{ $title := site.Title }}\n{{ $logo  := printf \"img/logos/%s\" site.Params.logos.footer | relURL }}\n{{ $year  := now.Year }}\n{{ $menu  := site.Menus.main }}\n{{ $btns  := dict \"btns\" site.Params.social \"color\" \"white\" \"outlined\" true }}\n<footer class=\"footer has-background-pattern\">\n\n  <div class=\"container\">\n    <div class=\"columns is-vcentered is-variable is-8\">\n      <div class=\"column is-one-third\">\n        <img class=\"is-footer-logo\" src=\"{{ $logo }}\" alt=\"KEDA Logo\">\n      </div>\n\n      <div class=\"column\">\n        {{ range $menu }}\n        {{ $isExternal := hasPrefix .URL \"http\" }}\n        <p class=\"is-size-4\">\n          <a href=\"{{ .URL }}\" class=\"has-text-white has-text-weight-semibold\">\n            <span>\n              {{ .Name }}\n            </span>\n            {{ if $isExternal }}\n            <span class=\"icon has-text-white-bis\">\n              <i class=\"fas fa-xs fa-up-right-from-square\"></i>\n            </span>\n            {{ end }}\n          </a>\n        </p>\n        {{ end }}\n      </div>\n\n      <div class=\"column\">     \n        <div class=\"buttons are-normal\">\n          {{ partial \"social-buttons.html\" $btns }}\n        </div>\n      </div>\n    </div>\n\n    <div class=\"has-text-weight-medium\">\n      <p>\n        &copy; KEDA Authors 2014-{{ $year }} | Documentation Distributed under <a href=\"https://creativecommons.org/licenses/by/4.0\" target=\"_blank\">CC-BY-4.0</a>\n      </p>\n      <img referrerpolicy=\"no-referrer-when-downgrade\" src=\"https://static.scarf.sh/a.png?x-pxid=46ce89e3-f6ce-454e-9740-490aaee3da5e\" />\n      <br />\n\n      <p>\n        &copy; {{ $year }} <a href=\"https://linuxfoundation.org\" target=\"_blank\">The Linux Foundation</a>. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our <a href=\"https://linuxfoundation.org/trademark-usage\" target=\"_blank\">Trademark Usage</a> page. \n      </p>\n    </div>\n  </div>\n</footer>\n"
  },
  {
    "path": "layouts/partials/general-version-selector.html",
    "content": "{{ $allVersions := site.Params.versions.docs }}\n{{ $latest      := index $allVersions 0 }}\n{{ $version     := \"\" }}\n{{ with .File }}{{ $version = index (split .Path \"/\") 1 }}{{ end }}\n{{ $isLatest    := eq $latest $version }}\n{{ $onlyOne     := eq (len $allVersions) 1 }}\n<div class=\"dropdown\" x-data=\"{ open: false }\" :class=\"{ 'is-active': open }\">\n  <div class=\"dropdown-trigger\">\n    <button class=\"button\" aria-haspopup=\"true\" aria-controls=\"dropdown-menu\" @click=\"open = !open\" @click.outside=\"open = false\">\n      Version\n      &nbsp;\n      <span class=\"has-text-weight-bold\">\n        {{ $version }}\n      </span>\n      {{ if $isLatest }}\n      &nbsp;\n      <span>\n        (latest)\n      </span>\n      {{ end }}\n      {{ if not $onlyOne }}\n      <span class=\"icon is-small has-text-primary\">\n        <i class=\"fas fa-angle-down\" aria-hidden=\"true\"></i>\n      </span>\n      {{ end }}\n    </button>\n  </div>\n  {{ if not $onlyOne }}\n  <div class=\"dropdown-menu\" id=\"dropdown-menu\" role=\"menu\">\n    <div class=\"dropdown-content\">\n      {{ range $allVersions }}\n      {{ $isLatest := eq . $latest }}\n      <a class=\"dropdown-item\" href=\"/docs/{{ . }}\">\n        <span>\n          {{ . }}\n        </span>\n        {{ if $isLatest }}\n        &nbsp;\n        <span>\n          (latest)\n        </span>\n        {{ end }}\n      </a>\n      {{ end }}\n    </div>\n  </div>\n  {{ end }}\n</div>"
  },
  {
    "path": "layouts/partials/headline-hash.html",
    "content": "{{ . | replaceRE \"(<h[2-9] id=\\\"([^\\\"]+)\\\".+)(</h[2-9]+>)\" `${1} <a class=\"headline-hash\" href=\"#${2}\">\n<span class=\"icon hashlink\"><i class=\"fas fa-link\"></i></span></a>${3}` | safeHTML }}\n"
  },
  {
    "path": "layouts/partials/hero.html",
    "content": "{{ $title := .Title }}\n{{ $desc  := .Description }}\n<section class=\"hero is-black is-medium has-background-pattern\">\n  <div class=\"hero-body\">\n    <div class=\"container\">\n      <p class=\"title is-size-1 is-size-2-mobile has-text-weight-bold{{ if $desc }} is-spaced{{ end }}\">\n        {{ .Title }}\n      </p>\n\n      {{ with $desc }}\n      <p class=\"subtitle is-size-3 is-size-4-mobile\">\n        {{ . }}\n      </p>\n      {{ end }}\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/home/cncf.html",
    "content": "{{ $logo := \"img/logos/cncf-color.png\" | relURL }}\n<section class=\"section\">\n  <div class=\"container has-text-centered\">\n    <p class=\"title is-size-3 is-size-4-mobile has-text-weight-semibold\">\n      KEDA is a <a id=\"cncf\" href=\"https://cncf.io\" target=\"_blank\">Cloud Native Computing Foundation</a> graduated project\n    </p>\n\n    <img class=\"is-cncf-logo\" src=\"{{ $logo }}\" alt=\"CNCF logo\">\n  </div>\n</section>\n"
  },
  {
    "path": "layouts/partials/home/features.html",
    "content": "{{ $features := site.Params.features }}\n<section class=\"section\">\n  <div class=\"container has-text-centered\">\n    <p style=\"padding:10px\" class=\"title is-inline-block underline--magical is-size-1 is-size-3-mobile\" id=\"features\">\n      Features\n    </p>\n\n    <br />\n\n    <div style=\"margin-top: 20px;\" class=\"columns is-multiline is-variable is-4\">\n      {{ range $features }}\n      <div class=\"column is-one-third\">\n        <div class=\"card has-no-shadow is-borderless has-extra-bottom-margin\">\n          <div class=\"card-content is-paddingless\">\n            <p class=\"title has-text-secondary is-spaced\">\n              <span class=\"icon\">\n               <i class=\"{{ .icon }} fa-2x\" alt=\"{{ .title }}\"></i>\n              </span>\n            </p>\n\n            <p class=\"subtitle is-size-3 is-size-4-mobile has-text-weight-bold\">\n              {{ .title }}\n            </p>\n     \n            <p class=\"content is-medium\">\n              {{ .content | markdownify }}\n            </p>\n          </div>\n        </div>\n      </div>\n      {{ end }}\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/home/get-involved.html",
    "content": "{{ with site.GetPage \"/community\" }}\n<section class=\"section has-background-light\">\n  <div class=\"container\">\n\t  <div class=\"has-text-centered\">\n\t\t<p class=\"title is-size-1 is-inline-block underline--magical-5 is-size-3-mobile\" id=\"get-involved\">\n      \t\tGet Involved\n    \t</p> \n\t  </div>\n    \n    <div style=\"margin-top:15px;\" class=\"content is-medium\">\n      {{ partial \"include.html\" \"get-involved.md\" }}\n    </div>\n  </div>\n</section>\n{{ end }}"
  },
  {
    "path": "layouts/partials/home/hero.html",
    "content": "{{ $logo   := printf \"img/logos/%s\" site.Params.logos.hero | relURL }}\n{{ $desc   := site.Params.description | markdownify }}\n{{ $btns   := site.Menus.buttons }}\n{{ $sect   := .Section }}\n{{ $docsL  := index site.Params.versions.docs 0 }}\n<section class=\"hero is-medium has-background-pattern\">\n  <div class=\"hero-body\">\n    <div class=\"container\">\n      <div class=\"columns is-vcentered is-variable is-8\">\n        <div class=\"column is-one-third\">\n          <img class=\"is-hero-logo\" src=\"{{ $logo }}\" alt=\"{{ site.Title }} home hero logo\">\n        </div>\n\n        <div class=\"column\">\n          <p class=\"title is-size-1 is-size-2-mobile has-text-white-bis has-text-weight-bold has-shadow is-spaced\">\n            Kubernetes Event-driven Autoscaling\n          </p>\n\n          <p class=\"subtitle is-size-3 has-text-light is-size-4-mobile has-shadow\">\n            {{ $desc }}\n          </p>\n\n          <br />\n\n          <div class=\"buttons\">\n            {{ range $btns }}\n            {{ $url := \"\" }}\n            {{ if (hasPrefix .URL \"/docs\") }}\n            {{ $url = replaceRE \"/docs\" (printf \"/docs/%s\" $docsL) .URL }}\n            {{ else if (hasPrefix .URL \"/http-add-on/\") }}\n            {{ $url = replace .URL \"/http-add-on/\" \"/http-add-on/latest/\" }}\n            {{ else }}\n            {{ $url = .URL }}\n            {{ end }}\n            <a class=\"button is-black is-inverted has-text-weight-bold\" href=\"{{ $url }}\">\n              {{ with .Pre }}\n              <span class=\"icon has-text-primary\">\n                <i class=\"{{ . }}\"></i>\n              </span>\n              {{ end }}\n              <span>\n                {{ .Name }}\n              </span>\n            </a>\n            {{ end }}\n          </div>\n        </div>\n      </div>\n    </div>\n  </div>\n</section>\n"
  },
  {
    "path": "layouts/partials/home/samples.html",
    "content": "{{ $samples := site.Params.samples }}\n<section class=\"section has-background-white-bis\">\n  <div class=\"container\">\n\t  <div class=\"has-text-centered\">\n\t\t<p style=\"padding:10px;\" class=\"title is-spaced is-size-1 is-size-3-mobile is-inline-block underline--magical-3\" id=\"samples\">\n      \t\tHighlighted Samples\n    \t</p>\n   \t\t<p class=\"subtitle is-size-4 is-size-5-mobile\">\n      \t\tWe provide a <a href=\"https://github.com/kedacore/samples\" target=\"_blank\">variety of samples</a>, but here are some of our highlights:\n    \t</p>\n\t  </div>\n\n    <div style=\"margin-top:20px\" class=\"columns\">\n      {{ range $samples }}\n      <div class=\"column is-one-third\">\n        <div class=\"card is-info-light\">\n          <div class=\"card-content\">\n            <p class=\"title is-size-2 is-size-3-mobile is-spaced\">\n              <span class=\"icon has-text-primary\">\n                <i class=\"{{ .icon }}\"></i>\n              </span>\n            </p>\n    \n            <p class=\"subtitle is-size-3 is-size-4-mobile has-text-weight-bold\">\n              <a href=\"{{ .url }}\" target=\"_blank\">\n                {{ .title }}\n              </a>\n            </p>\n    \n            <p class=\"content is-medium\">\n              {{ .content | markdownify }}\n            </p>\n          </div>\n        </div>\n      </div>\n      {{ end }}\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/home/scalers.html",
    "content": "{{ $latest  := index site.Params.versions.docs 0 }}\n{{ $scalers := where site.RegularPages \".CurrentSection.Title\" \"Scalers\" }}\n<section class=\"section\">\n  <div class=\"container\">\n\t  <div class=\"has-text-centered\">\n\t\t<p style=\"padding:10px\"  \n\t\t   class=\"title is-inline-block is-size-1 is-size-3-mobile is-spaced underline--magical-2 \" id=\"scalers\">\n      Scalers\n    \t</p>\n\n    \t<p class=\"subtitle has-text-dark is-size-4 is-size-5-mobile has-text-centered\">\n     \t\tScalers represent event sources that KEDA can scale based on\n    \t</p>\t  \n\t  </div>\n\n    <br />\n\n    <div style=\"margin-top:20px\" class=\"columns is-multiline\">\n      {{ range $scalers }}\n      {{ $version := index (split .File.Path \"/\") 1 }}\n      {{ if eq $version $latest }}\n      {{ .Render \"card-info\" }}\n      {{ end }}\n      {{ end }}\n    </div>\n  </div>\n</section>\n"
  },
  {
    "path": "layouts/partials/home/video.html",
    "content": "<section class=\"section has-background-black has-background-pattern\">\n  <div class=\"container\">\n    <div class=\"columns is-vcentered\">\n      <div class=\"column\">\n        {{ partial \"youtube-embed.html\" (dict \"youtube_id\" \"317rLOIKfDQ\") }}\n      </div>\n\n      <div class=\"column\">\n        <p class=\"title has-text-white-bis is-spaced\">\n          KEDA: Unlocking Advanced Event-Driven Scaling for Kubernetes\n        </p>\n\n        <p class=\"subtitle has-text-light\">\n          From KubeCon Europe 2025\n        </p>\n      </div>\n    </div>\n    <div class=\"columns is-vcentered\">\n      <div class=\"column\">\n        <p class=\"title has-text-white-bis is-spaced\">\n          Scaling New Heights with KEDA: Performance, Extensions, and Beyond\n        </p>\n\n        <p class=\"subtitle has-text-light\">\n          From KubeCon Europe 2024\n        </p>\n      </div>\n\n      <div class=\"column\">\n        {{ partial \"youtube-embed.html\" (dict \"youtube_id\" \"_5_njiPr5vg\") }}\n      </div>\n    </div>\n    <div class=\"columns is-vcentered\">\n      <div class=\"column\">\n        {{ partial \"youtube-embed.html\" (dict \"youtube_id\" \"wYQ2cvSj6os\") }}\n      </div>\n\n      <div class=\"column\">\n        <p class=\"title has-text-white-bis is-spaced\">\n          Exploring KEDA's Graduation and Advancements in Event-Driven Scaling\n        </p>\n\n        <p class=\"subtitle has-text-light\">\n          From KubeCon North America 2023\n        </p>\n      </div>\n    </div>\n  </div>\n</section>\n"
  },
  {
    "path": "layouts/partials/home/what-is.html",
    "content": "{{ $whatIs := site.Params.what_is | markdownify }}\n<section class=\"section has-background-light\">\n  <div class=\"container\">\n    <div class=\"columns is-vcentered is-flexible is-8\">\n      <div class=\"column is-one-third\">\n        <p style=\"padding:10px\" class=\"title is-inline-block is-size-1 is-size-3-mobile underline--magical-1\">\n          What is KEDA?\n        </p>\n      </div>\n\n      <div class=\"column\">\n        <div class=\"content is-medium\">\n          {{ $whatIs }}\n        </div>\n      </div>\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/include.html",
    "content": "{{ $path := printf \"includes/%s\" . }}\n{{ readFile $path | markdownify }}"
  },
  {
    "path": "layouts/partials/javascript.html",
    "content": "{{ $inDevMode     := not hugo.IsProduction }}\n\n{{/* Alpine.js */}}\n{{ $alpine := resources.Get \"js/alpine.js\" | js.Build (dict \"targetPath\" \"js/alpine.js\") }}\n{{ if $inDevMode }}\n<script src=\"{{ $alpine.RelPermalink }}\" defer></script>\n{{ else }}\n{{ $alpine = $alpine | minify | fingerprint }}\n<script src=\"{{ $alpine.RelPermalink }}\" integrity=\"{{ $alpine.Data.Integrity }}\" defer></script>\n{{ end }}\n\n{{/* DocSearch */}}\n{{ $latestDocs := index site.Params.versions.docs 0 }}\n{{ $latestHttpAddon := \"\" }}\n{{ with index site.Params.versions \"http-add-on\" }}{{ $latestHttpAddon = index . 0 }}{{ end }}\n{{ $dsParams := dict \"latestDocs\" $latestDocs \"latestHttpAddon\" $latestHttpAddon \"apiKey\" site.Params.docsearch.apiKey \"appId\" site.Params.docsearch.appId \"indexName\" site.Params.docsearch.indexName }}\n{{ $docsearchOpts := dict \"targetPath\" \"js/docsearch.js\" \"params\" $dsParams }}\n{{ $docsearch := resources.Get \"js/docsearch.js\" | js.Build $docsearchOpts }}\n{{ if $inDevMode }}\n<script src=\"{{ $docsearch.RelPermalink }}\" defer></script>\n{{ else }}\n{{ $docsearch = $docsearch | minify | fingerprint }}\n<script src=\"{{ $docsearch.RelPermalink }}\" integrity=\"{{ $docsearch.Data.Integrity }}\" defer></script>\n{{ end }}\n\n{{/* Scaler search and filter (bundles Lunr.js) */}}\n{{ $scalerSearch := resources.Get \"js/scaler-search.js\" | js.Build (dict \"targetPath\" \"js/scaler-search.js\") }}\n{{ if $inDevMode }}\n<script src=\"{{ $scalerSearch.RelPermalink }}\" defer></script>\n{{ else }}\n{{ $scalerSearch = $scalerSearch | minify | fingerprint }}\n<script src=\"{{ $scalerSearch.RelPermalink }}\" integrity=\"{{ $scalerSearch.Data.Integrity }}\" defer></script>\n{{ end }}\n\n{{/* Site utilities (anchor offset, clipboard, FAQ accordion) */}}\n{{ $site := resources.Get \"js/site.js\" | js.Build (dict \"targetPath\" \"js/site.js\") }}\n{{ if $inDevMode }}\n<script src=\"{{ $site.RelPermalink }}\" defer></script>\n{{ else }}\n{{ $site = $site | minify | fingerprint }}\n<script src=\"{{ $site.RelPermalink }}\" integrity=\"{{ $site.Data.Integrity }}\" defer></script>\n{{ end }}\n"
  },
  {
    "path": "layouts/partials/logo-section.html",
    "content": "<section class=\"section\">\n  <div class=\"container\">\n\t  <div class=\"has-text-centered\">\n\t\t<p style=\"padding:10px;\" class=\"title is-size-1 is-size-3-mobile is-spaced is-inline-block underline--magical-4\">\n      \t\t{{ .title }}\n    \t</p>\n\n    \t<p class=\"subtitle is-size-4 is-size-5-mobile\">\n      \t\t{{ .description }}\n    \t</p>\n\t  </div>\n\n    <br />\n\n    <div style=\"margin-top:20px\" class=\"columns is-centered is-multiline is-vcentered is-variable is-8\">\n      {{ range .logos }}\n      {{ $logo := printf \"img/logos/%s\" .logo | relURL }}\n      <div class=\"column is-one-quarter\">\n        <a href=\"{{ .url }}\" target=\"_blank\">\n          \t<img src=\"{{ $logo }}\" alt=\"Logo\">\n        </a>\n      </div>\n      {{ end }}\n    </div>\n  </div>\n</section>"
  },
  {
    "path": "layouts/partials/meta.html",
    "content": "{{ $url           := .Permalink }}\n{{ $latestVersion := index site.Params.versions.docs 0 -}}\n{{ $canonical     := replaceRE \"/docs/\\\\d.\\\\d+\" (printf \"/docs/%s\" $latestVersion) $url }}\n{{ $title         := cond .IsHome site.Title (printf \"%s | %s\" site.Title .Title) }}\n{{ $type          := cond .IsHome \"website\" \"article\" }}\n{{ $desc          := cond .IsHome site.Params.description .Description }}\n{{ $twitter       := site.Params.twitter_handle }}\n{{ $img           := \"img/logos/keda-icon-color.png\" | absURL }}\n{{ $imgAlt        := printf \"%s color logo\" site.Title }}\n{{ $locale        := site.Params.locale }}\n{{ $sectionVersions := index site.Params.versions .Section }}\n{{ $version       := \"\" }}\n{{ if $sectionVersions }}\n{{ with .File }}{{ $version = index (split .Path \"/\") 1 }}{{ end }}\n{{ end }}\n<meta charset=\"utf-8\">\n<meta name=\"viewport\" content=\"width=device-width, initial-scale=1, shrink-to-fit=no\">\n\n{{ with .OutputFormats.Get \"rss\" -}}\n{{ printf `<link rel=\"%s\" type=\"%s\" href=\"%s\" title=\"%s\" />` .Rel .MediaType.Type $url site.Title | safeHTML }}\n{{ end -}}\n\n<link rel=\"canonical\" href=\"{{ $canonical }}\">\n\n{{/*\nWhen $version is a released version that is not the latest,\nadd a \"noindex\" meta tag to exclude it from search engines.\nUnreleased and latest versions remain indexable.\n*/}}\n{{ if ne $version \"\" }}\n{{ $isOldVersion := and (in $sectionVersions $version) (ne $version (index $sectionVersions 0)) }}\n{{ if $isOldVersion }}\n<meta name=\"robots\" content=\"noindex\">\n{{ end }}\n{{ end }}\n\n{{/* Twitter Card metadata */}}\n<meta name=\"twitter:card\" content=\"summary\">\n<meta name=\"twitter:site\" content=\"{{ $twitter }}\">\n<meta name=\"twitter:creator\" content=\"{{ $twitter }}\">\n<meta name=\"twitter:image\" content=\"{{ $img }}\">\n<meta name=\"twitter:image:alt\" content=\"{{ $imgAlt }}\">\n\n{{ $tag := .Section }}\n{{ if ne $version \"\" }}{{ $tag = printf \"%s-%s\" .Section $version }}{{ end }}\n<meta name=\"docsearch:language\" content=\"en\" />\n<meta name=\"docsearch:product\" content=\"{{ .Section }}\" />\n<meta name=\"docsearch:version\" content=\"{{ $version }}\" />\n<meta name=\"docsearch:tag\" content=\"{{ $tag }}\" />\n\n{{/* OpenGraph metadata */}}\n<meta property=\"og:url\" content=\"{{ $url }}\">\n<meta property=\"og:title\" content=\"{{ $title }}\">\n{{ with $desc }}\n<meta property=\"og:description\" content=\"{{ $desc }}\">\n{{ end }}\n<meta property=\"og:type\" content=\"{{ $type }}\">\n<meta property=\"og:site_name\" content=\"{{ site.Title }}\">\n<meta property=\"og:image\" content=\"{{ $img }}\">\n<meta property=\"og:image:type\" content=\"image/png\">\n<meta property=\"og:image:alt\" content=\"{{ $imgAlt }}\">\n<meta property=\"og:locale\" content=\"{{ $locale }}\">\n\n{{ if hugo.IsProduction -}}\n  {{ template \"_internal/google_analytics.html\" . -}}\n{{ end -}}\n"
  },
  {
    "path": "layouts/partials/nav.html",
    "content": "{{ $here           := .RelPermalink }}\n{{ $docs           :=  where site.Sections \"Section\" .Section }}\n{{ $currentSection := .CurrentSection }}\n{{ $root           := .FirstSection }}\n{{ $thisVersion    := index (split .File.Path \"/\") 1 }}\n<div class=\"nav\">\n  {{ range $docs }}\n  {{ range .Sections }}\n  {{ $version := index (split .File.Path \"/\") 1 }}\n  {{ $sameVersion := eq $version $thisVersion }}\n  {{ if $sameVersion }}\n  {{ $isThisSection := eq .CurrentSection.Title $currentSection.Title }}\n  {{ $isHere := eq $here .RelPermalink }}\n  <div class=\"nav-section\" x-data=\"{ open: {{ $isThisSection }} }\">\n    <div class=\"nav-section-title is-size-5 is-size-6-mobile{{ if $isHere }} is-active{{ end }}\" href=\"{{ .RelPermalink }}\">\n      <a href=\"{{ .RelPermalink }}\">\n        {{ .Title }}\n      </a>\n      {{ if .RegularPages }}\n      <span @click=\"open = !open\">\n        <i class=\"fas fa-md has-text-secondary\" :class=\"{ 'fa-caret-down': !open, 'fa-caret-up': open }\"></i>\n      </span>\n      {{ end }}\n    </div>\n\n    {{ with .RegularPages }}\n    <ul class=\"nav-section-links\" x-show=\"open\">\n      {{ range . }}\n      {{ $isHere := eq $here .RelPermalink }}\n      {{ $title := cond (isset .Params \"short\") .Params.short .Title }}\n      <li class=\"nav-section-link{{ if $isHere }} is-active{{ end }}\">\n        <a href=\"{{ .RelPermalink }}\">\n          {{ $title }}\n        </a>\n      </li>\n\n      {{ if $isHere }}\n      {{ if gt (len .TableOfContents) 32 }}\n      <div class=\"nav-section-toc\">\n        {{ .TableOfContents }}\n      </div>\n      {{ end }}\n      {{ end }}\n      {{ end }}\n    </ul>\n    {{ end }}\n  </div>\n\n  {{ with .Sections }}\n  {{ range . }}\n  {{ $isThisSection := eq .CurrentSection.Title $currentSection.Title }}\n  {{ $regularPages := .RegularPages -}}\n  <div class=\"nav-subsection\" x-data=\"{ open: {{ $isThisSection }} }\">\n    <div class=\"nav-section-title is-size-5 is-size-6-mobile{{ if $isHere }} is-active{{ end }}\" href=\"{{ .RelPermalink }}\">\n      <a href=\"{{ .RelPermalink }}\">\n        {{ .Title }}\n      </a>\n      {{ if $regularPages }}\n      <span @click=\"open = !open\">\n        <i class=\"fas fa-md has-text-secondary\" :class=\"{ 'fa-caret-down': !open, 'fa-caret-up': open }\"></i>\n      </span>\n      {{ end }}\n    </div>\n\n    {{ with $regularPages }}\n    <ul class=\"nav-section-links\" x-show=\"open\">\n      {{ range . }}\n      {{ $isHere := eq $here .RelPermalink }}\n      {{ $title := cond (isset .Params \"short\") .Params.short .Title }}\n      <li class=\"nav-section-link{{ if $isHere }} is-active{{ end }}\">\n        <a href=\"{{ .RelPermalink }}\">\n          {{ $title }}\n        </a>\n      </li>\n\n      {{ if $isHere }}\n      {{ if gt (len .TableOfContents) 32 }}\n      <div class=\"nav-section-toc\">\n        {{ .TableOfContents }}\n      </div>\n      {{ end }}\n      {{ end }}\n      {{ end }}\n    </ul>\n    {{ end }}\n  </div>\n  {{ end }}\n  {{ end }}\n\n  {{ end }} <!-- docs with same version -->\n  {{ end }} <!-- versions -->\n  {{ end }} <!-- docs sections -->\n</div>\n"
  },
  {
    "path": "layouts/partials/navbar.html",
    "content": "{{ $home     := site.BaseURL }}\n{{ $here     := .RelPermalink }}\n{{ $logo     := site.Params.logos.navbar }}\n{{ $menu     := site.Menus.main }}\n{{ $docs     := site.Menus.docs }}\n{{ $social   := site.Params.social }}\n{{ $scalers  := where site.RegularPages \".CurrentSection.Title\" \"Scalers\" }}\n<nav id=\"mainnav\" style=\"padding:10px\" class=\"navbar is-transparent has-background-pattern is-fixed-top\" role=\"navigation\" aria-label=\"main navigation\" x-data=\"{ open: false, scrolled: false }\" @scroll.window=\"scrolled = window.scrollY > $el.offsetHeight\" :class=\"{ 'scrolled': scrolled }\">\n  <div class=\"container\">\n    <div class=\"navbar-brand is-left-padded\" style=\"align-items: end;\">\n      <a class=\"navbar-item\" href=\"{{ $home }}\">\n        {{ $url := printf \"img/logos/%s\" $logo | relURL }}\n        <img src=\"{{ $url }}\" style=\"transform: scale(2);\" height=\"28\" width=\"66\" alt=\"Keda logo\">\n      </a>\n\n      <a role=\"button\" class=\"navbar-burger\" data-target=\"navbar-menu\" aria-label=\"menu\" aria-expanded=\"false\" @click=\"open = !open\" @click.outside=\"open = false\" :class=\"{ 'is-active': open }\">\n        <span aria-hidden=\"true\"></span>\n        <span aria-hidden=\"true\"></span>\n        <span aria-hidden=\"true\"></span>\n      </a>\n    </div>\n\n    <div class=\"navbar-menu\" id=\"navbar-menu\" :class=\"{ 'is-active': open }\">\n      <div class=\"navbar-end\">\n        <div class=\"navbar-item\" id=\"navbar-search\">\n          <p class=\"control has-icons-left\">\n            <input class=\"input is-rounded\" type=\"text\" placeholder=\"Search\" id=\"search-bar\">\n            <span class=\"icon is-small is-left\">\n              <i class=\"fas fa-magnifying-glass\"></i>\n            </span>\n          </p>\n        </div>\n\n        <!-- docs menu for mobile showing nested items -->\n        <div class=\"docs-menu--mobile navbar-item is-size-5-desktop has-dropdown is-hoverable\">\n          {{ with .Site.Menus.docs }}\n          <div class=\"navbar-item is-size-5-desktop has-dropdown is-hoverable\">\n            {{ range . }}\n              {{ template \"main_nav_item\" . }}\n            {{ end }}\n          </div>\n          {{ end }}\n        </div>\n        \n        {{ define \"main_nav_item\" }}\n        {{ $url := replace .URL \"/docs\" \"/docs/latest\" }}\n        {{ $url  = replace $url \"/http-add-on/\" \"/http-add-on/latest/\" }}\n        {{ $isExternal := hasPrefix .URL \"http\" }}\n        {{ if .Params.prependDivider }}<hr class=\"navbar-divider\">{{ end }}\n        <div class=\"navbar-item is-size-5-desktop has-dropdown is-hoverable\">\n          <a class=\"navbar-link is-arrowless\"{{ with $url }} href=\"{{ . }}\"{{ end }} {{ if $isExternal }} target=\"_blank\"{{ end }}>\n            <span>\n              {{ .Name }}\n            </span>\n            {{ if $isExternal }}\n              <span class=\"icon\">\n                <i class=\"fas fa-xs fa-up-right-from-square\"></i>\n              </span>\n              {{ end }}\n              {{ if .HasChildren }}\n            <span class=\"icon\">\n              <i class=\"fas fa-md fa-caret-down\"></i>\n            </span>\n            {{ end }}\n          </a>\n          {{ if .HasChildren }}\n            <div class=\"navbar-dropdown is-radiusless\">\n              {{ range .Children }}\n                {{ template \"main_nav_item\" . }}\n              {{ end }}\n            </div>\n          {{ end }}\n          </div>\n        {{ end }}\n\n        <!-- docs menu for desktop hiding nested items   -->\n        {{ range $docs }}\n        {{ $isExternal := hasPrefix .URL \"http\" }}\n        {{ if .HasChildren }}\n        {{ $url := replace .URL \"/docs\" \"/docs/latest\" }}\n        {{ $url  = replace $url \"/http-add-on/\" \"/http-add-on/latest/\" }}\n        <div class=\"docs-menu--desktop navbar-item is-size-5-desktop has-dropdown is-hoverable\">\n          <a class=\"navbar-link is-arrowless\"{{ with $url }} href=\"{{ . }}\"{{ end }}>\n            <span>\n              {{ .Name }}\n            </span>\n            <span class=\"icon has-text-white\">\n              <i class=\"fas fa-md fa-caret-down\"></i>\n            </span>\n          </a>\n\n          <div class=\"navbar-dropdown is-radiusless\">\n            {{ range .Children }}\n            {{ $isExternal := hasPrefix .URL \"http\" }}\n            {{ $url := replace .URL \"/docs\" \"/docs/latest\" }}\n            {{ $url  = replace $url \"/http-add-on/\" \"/http-add-on/latest/\" }}\n            {{ if .Params.prependDivider }}<hr class=\"navbar-divider\">{{ end }}\n            <a class=\"navbar-item\" href=\"{{ $url }}\"{{ if $isExternal }} target=\"_blank\"{{ end }}>\n              <span>\n                {{ .Name }}\n              </span>\n              {{ if $isExternal }}\n              <span class=\"icon has-text-white\">\n                <i class=\"fas fa-xs fa-up-right-from-square\"></i>\n              </span>\n              {{ end }}\n            </a>\n            {{ end }}\n          </div>\n        </div>\n        {{ end }}\n        {{ end }}\n\n        {{ range $menu }}\n        {{ $isExternal := hasPrefix .URL \"http\" }}\n        {{ if .HasChildren }}\n        <div class=\"navbar-item is-size-5-desktop has-dropdown is-hoverable\">\n          <a class=\"navbar-link is-arrowless\"{{ with .URL }} href=\"{{ . }}\"{{ end }}>\n            <span>\n              {{ .Name }}\n            </span>\n            <span class=\"icon has-text-white\">\n              <i class=\"fas fa-md fa-caret-down\"></i>\n            </span>\n          </a>\n\n          <div class=\"navbar-dropdown is-radiusless\">\n            {{ range .Children }}\n            {{ $isExternal := hasPrefix .URL \"http\" }}\n            <a class=\"navbar-item\" href=\"{{ .URL }}\"{{ if $isExternal }} target=\"_blank\"{{ end }}>\n              <span>\n                {{ .Name }}\n              </span>\n              {{ if $isExternal }}\n              <span class=\"icon has-text-white\">\n                <i class=\"fas fa-xs fa-up-right-from-square\"></i>\n              </span>\n              {{ end }}\n            </a>\n            {{ end }}\n          </div>\n        </div>\n        {{ else }}\n        <a class=\"navbar-item is-size-5-desktop\" href=\"{{ .URL }}\"{{ if $isExternal }} target=\"_blank\"{{ end }}>\n          <span>\n            {{ .Name }}\n          </span>\n          {{ if $isExternal }}\n          <span class=\"icon has-text-white\">\n            <i class=\"fas fa-xs fa-up-right-from-square\"></i>\n          </span>\n          {{ end }}\n        </a>\n        {{ end }}\n        {{ end }}\n\n        <div class=\"navbar-item\">\n          <div class=\"buttons\">\n            {{ partial \"social-buttons.html\" (dict \"btns\" $social \"compact\" true \"color\" \"dark\") }}\n          </div>\n        </div>\n      </div>\n    </div>\n  </div>\n</nav>\n"
  },
  {
    "path": "layouts/partials/scaler-layout.html",
    "content": "<h2 id=\"available-scalers\">Currently available scalers for KEDA</h2>\n<div style=\"display: flex; justify-content: flex-end\">\n  <form\n    class=\"control has-icons-left has-extra-sm-right-margin\"\n    id=\"search\"\n    role=\"search\"\n  >\n    <input\n      class=\"input is-rounded\"\n      type=\"search\"\n      placeholder=\"Search for scalers\"\n      id=\"search-input\"\n    />\n    <span class=\"icon is-small is-left\">\n      <i class=\"fas fa-magnifying-glass\"></i>\n    </span>\n  </form>\n</div>\n<div class=\"columns\">\n  <div class=\"filter-pane\">\n    <h5>FILTER <span class=\"filter-icon\"><i class=\"fas fa-filter\"></i></span></h5>\n    <div class=\"filter-options\">\n      <div class=\"has-extra-top-margin\">\n        <h6>Type</h6>\n        <div>\n          <input id=\"built-in\" type=\"checkbox\" name=\"resource_filter\" value=\"type:built-in\">\n          <label for=\"built-in\">Built-in</label>\n        </div>\n        <div>\n          <input id=\"external\" type=\"checkbox\" name=\"resource_filter\" value=\"type:external\">\n          <label for=\"external\">External</label>\n        </div>\n      </div>\n      <div class=\"has-extra-top-margin\">\n        <h6>Category</h6>\n        {{ $categories := slice }}\n        {{ range $scalers :=  where site.RegularPages \".CurrentSection.Title\" \"Scalers\" }}\n          {{ with $scalers.Params.category }}\n              {{ $categories = $categories | append ($scalers.Params.category) }}\n              {{ $categories = uniq $categories }}\n          {{ end }}\n        {{ end }}\n        {{ range $categories }}\n        {{ $category := . }}\n        <div>\n            <input id=\"{{ . }}\" type=\"checkbox\" name=\"resource_filter\" value=\"category:{{ . }}\">\n            <label for=\"{{ . }}\">{{ . }}</label>\n        </div>\n        {{ end }}\n      </div>    \n      <div class=\"has-extra-top-margin\">\n        <h6>Maintainer</h6>\n        {{ $maintainers := slice }}\n        {{ range $scalers :=  where site.RegularPages \".CurrentSection.Title\" \"Scalers\" }}\n            {{ $maintainers = $maintainers | append ($scalers.Params.maintainer) }}\n            {{ $maintainers = uniq $maintainers }}\n        {{ end }}\n        {{ range $maintainers }}\n        {{ $maintainer := . }}\n        <div>\n            <input id=\"{{ . }}\" type=\"checkbox\" name=\"resource_filter\" value=\"maintainer:{{ . }}\">\n            <label for=\"{{ . }}\">{{ . }}</label>\n        </div>\n        {{ end }}\n        <div>\n          <input id=\"keda\" type=\"checkbox\" name=\"resource_filter\" value=\"maintainer:keda\">\n          <label for=\"keda\">Keda</label>\n        </div>\n        <div>\n          <input id=\"wsugarman\" type=\"checkbox\" name=\"resource_filter\" value=\"maintainer:wsugarman\">\n          <label for=\"wsugarman\">Wsugarman</label>\n        </div>\n        <div>\n          <input id=\"JensWalter\" type=\"checkbox\" name=\"resource_filter\" value=\"maintainer:JensWalter\">\n          <label for=\"JensWalter\">JensWalter</label>\n        </div>\n      </div>\n    </div>   \n  </div>\n  <div class=\"results-pane column\">\n    <div class=\"results\"></div>\n    <div\n      id=\"scalers\"\n      style=\"margin-top: 20px\"\n      class=\"columns is-multiline is-search-result\"\n    >\n      {{ partial \"scaler-template\" . }}\n    </div>\n  </div>\n</div>\n"
  },
  {
    "path": "layouts/partials/scaler-template.html",
    "content": "<template id=\"is-search-template\">\n  <div class=\"column is-half\">\n    <div class=\"card\">\n      <div class=\"card-content\">\n        <p class=\"badge is-pulled-right\"></p>\n        <a\n          class=\"title is-size-4 is-size-5-mobile has-text-primary has-text-weight-bold scaler-title\"\n        >\n        </a>\n\n        <br /><br />\n\n        <div class=\"content is-medium description\"></div>\n      </div>\n\n      <footer class=\"card-footer\">\n        <div class=\"card-footer-item is-spaced card-is-wrapped\">\n          Availability:&nbsp;<span\n            class=\"has-text-weight-bold availability\"\n          ></span>\n        </div>\n\n        <div class=\"card-footer-item card-is-wrapped\">\n          Maintainer:&nbsp;<span class=\"has-text-weight-bold maintainer\"></span>\n        </div>\n      </footer>\n    </div>\n  </div>\n</template>\n"
  },
  {
    "path": "layouts/partials/scalers.html",
    "content": "{{ $here    := $.Page.RelPermalink }}\n{{ $scalers := where site.RegularPages \".CurrentSection.Title\" \"Scalers\" }}\n{{ $version := index (split $.Page.File.Path \"/\") 1 }}\n<div class=\"buttons has-extra-top-margin\">\n  {{ range $scalers }}\n  {{ $isHere      := eq .RelPermalink $here }}\n  {{ $thisVersion := index (split .File.Path \"/\") 1 }}\n  {{ $sameVersion := eq $version $thisVersion }}\n  {{ if $sameVersion }}\n  <a class=\"button is-primary{{ if not $isHere }} is-outlined{{ end }}\" href=\"{{ .RelPermalink }}\">\n    {{ .Title }}\n  </a>\n  {{ end }}\n  {{ end }}\n</div>\n"
  },
  {
    "path": "layouts/partials/social-buttons.html",
    "content": "{{ $compact  := .compact }}\n{{ $outlined := .outlined }}\n{{ range .btns }}\n<a class=\"button is-{{ .bg_color }}\" href=\"{{ .url }}\" target=\"_blank\" rel=\"noopener noreferrer\" aria-label=\"{{ .name }}\">\n  <span class=\"icon has-text-{{ .icon_color }}\">\n    <i class=\"{{ .icon }}\"></i>\n  </span>\n\n  {{ if not $compact }}\n  <span class=\"has-text-weight-bold has-text-{{ .text_color }}\">\n    {{ .name }}\n  </span>\n  {{ end }}\n</a>\n{{ end }}\n"
  },
  {
    "path": "layouts/partials/youtube-embed.html",
    "content": "{{ $src := printf \"https://www.youtube.com/embed/%s\" .youtube_id }}\n<iframe title=\"An overview of KEDA\" class=\"is-youtube-embed\" src=\"{{ $src }}\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen loading=\"lazy\"></iframe>"
  },
  {
    "path": "layouts/scalers/list.html",
    "content": "{{ define \"title\" }}\nKEDA Scalers\n{{ end }}\n\n{{ define \"main\" }}\n<div class=\"container\">\n  <div class=\"columns is-variable is-8\">\n    <div class=\"column is-one-quarter is-hidden-touch\">\n      {{ partial \"nav.html\" . }}\n    </div>\n\n    <div class=\"column is-three-quarters is-content-column\">\n      {{ partial \"docs/hero.html\" . }}\n      {{ partial \"content.html\" . }}\n    </div>\n  </div>\n</div>\n{{ end }}"
  },
  {
    "path": "layouts/shortcodes/authentication-providers.html",
    "content": "{{ $here    := $.Page.RelPermalink }}\n{{ $providers := where site.RegularPages \".CurrentSection.Title\" \"Authentication Providers\" }}\n{{ $version := index (split $.Page.File.Path \"/\") 1 }}\n<div class=\"buttons has-extra-top-margin\">\n  {{ range $providers }}\n  {{ $thisVersion := index (split .File.Path \"/\") 1 }}\n  {{ $sameVersion := eq $version $thisVersion }}\n  {{ if $sameVersion }}\n  <a class=\"button is-primary is-outlined\" href=\"{{ .RelPermalink }}\">\n    {{ .Title }}\n  </a>\n  {{ end }}\n  {{ end }}\n</div>\n"
  },
  {
    "path": "layouts/shortcodes/collapsible.html",
    "content": "<div class=\"card is-collapsible\" x-data=\"{ open: false }\">\n  <header class=\"has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ .Get 0 }}\n    </p>\n  </header>\n  <div class=\"card-content\" x-show=\"open\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ .Inner | markdownify }}\n    </div>\n  </div>\n</div>"
  },
  {
    "path": "layouts/shortcodes/enterprise.html",
    "content": "{{ $vendors := site.Params.vendors }}\n<div class=\"columns is-multiline is-centered\">\n  {{ range $vendors }}\n  <div class=\"column is-12\">\n    <div class=\"card\">\n      <div class=\"card-content\">\n        <!-- Logo Section -->\n        <div style=\"text-align: left; margin-bottom: 1rem;\">\n          <img src=\"{{ printf \"img/logos/%s\" .logo | relURL }}\" alt=\"{{ .name }}\" style=\"max-width: 200px; height: auto;\">\n        </div>\n        <!-- Description Section -->\n        <div class=\"content\" style=\"text-align: left; margin-bottom: 1rem;\">\n          {{ .description | markdownify }}\n        </div>\n        <hr />\n        <!-- Buttons Section -->\n        <div class=\"buttons\" style=\"text-align: left;\">\n          {{ range .urls }}\n          <a href=\"{{ .url }}\" target=\"_blank\" class=\"button has-background-info has-text-white has-text-weight-bold\">{{ .text }}</a>\n          {{ end }}\n        </div>\n      </div>\n    </div>\n  </div>\n  {{ end }}\n</div>\n\n<!-- Listing Requirements -->\n<br/>\n<div class=\"content\" style=\"max-width: 960px; margin: 0 auto 2rem auto;\">\n  <h2>Requirements for Listing a Vendor</h2>\n  <p>To be listed as a KEDA commercial offering, organizations must meet the following criteria:</p>\n  <ul>\n    <li>\n      Demonstrate a commitment to KEDA's maintenance and improvement.\n      <ul>\n        <li>On average, have pull requests accepted monthly into KEDA or related projects for features and/or improvements.</li>\n        <li>Have made a substantial contribution to the development of KEDA or related projects.</li>\n        <li>Help triage and comment on issues across the KEDA ecosystem at least 3 times per month.</li>\n      </ul>\n    </li>\n    <li>\n      Demonstrate an area of expertise in the KEDA ecosystem.\n      <ul>\n        <li>Example: Employing one or more KEDA maintainers.</li>\n        <li>Example: Owning a specific high-impact feature or process.</li>\n      </ul>\n    </li>\n    <li>\n      Participate in KEDA's governance.\n      <ul>\n        <li>At least 1 member of the vendor's team attends the community meetings at least 50% of the time.</li>\n      </ul>\n    </li>\n    <li>\n      Be active KEDA thought leaders.\n      <ul>\n        <li>Example: Sponsoring staff for KEDA booths or community events.</li>\n        <li>Example: Giving talks related to KEDA or its ecosystem.</li>\n      </ul>\n    </li>\n    <li>Provide enterprise-level support and functionality for KEDA or products based directly on it.</li>\n  </ul>\n  <p>If any questions arise regarding eligibility, the KEDA maintainers will make the final decision.</p>\n</div>\n"
  },
  {
    "path": "layouts/shortcodes/faq.html",
    "content": "{{ $faq := hugo.Data.faq.qna }}\n\n{{ range $faq }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n  </header>\n  <div class=\"card-content\" x-show=\"open\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n"
  },
  {
    "path": "layouts/shortcodes/faq20.html",
    "content": "{{ $filename := .Get \"versionData\" }}\n{{ range index hugo.Data $filename }}\n  {{ $.Scratch.Add \"faq20\" . }}\n{{ end }}\n\n{{ $faq20 := $.Scratch.Get \"faq20\" }}\n\n<h2 id=\"general\">General</h2>\n\n{{ range where $faq20 \".type\" \"==\" \"General\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n\n<h2 id=\"best-practices\">Best Practices</h2>\n\n{{ range where $faq20 \".type\" \"==\" \"Best Practices\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n\n<h2 id=\"features\">Features</h2>\n\n{{ range where $faq20 \".type\" \"==\" \"Features\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n\n<h2 id=\"kubernetes\">Kubernetes</h2>\n\n{{ range where $faq20 \".type\" \"==\" \"Kubernetes\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n\n<h2 id=\"community\">Community</h2>\n\n{{ range where $faq20 \".type\" \"==\" \"Community\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n\n<h2 id=\"website\">Website</h2>\n\n{{ range where $faq20 \".type\" \"==\" \"Website\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n\n<h2 id=\"integrations\">Integrations</h2>\n\n<h3>Microsoft Azure</h3>\n\n{{ range where $faq20 \".type\" \"==\" \"Azure\" }}\n{{ $question := .q | markdownify }}\n{{ $answer   := .a | markdownify }}\n{{ $id       := .q | urlize }}\n<div class=\"card is-collapsible\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header has-mouse-icon\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $question }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $answer }}\n    </div>\n  </div>\n</div>\n{{ end }}\n"
  },
  {
    "path": "layouts/shortcodes/include.html",
    "content": "{{ partial \"include.html\" (.Get 0) }}"
  },
  {
    "path": "layouts/shortcodes/integrations.html",
    "content": "{{ $latest  := index site.Params.versions.docs 0 }}\n{{ $integrations := where site.RegularPages \".CurrentSection.Title\" \"Integrations\" }}\n\n<div class=\"container\">\n  <div style=\"margin-top:20px\" class=\"columns is-variable is-multiline\">\n    {{ range $integrations }}\n      {{ $version := index (split .File.Path \"/\") 1 }}\n      {{ if eq $version $latest }}\n        {{ .Render \"card-info\" }}\n      {{ end }}\n    {{ end }}\n  </div>\n</div>\n\n"
  },
  {
    "path": "layouts/shortcodes/partners-icons.html",
    "content": "{{ $companies := site.Params.partners }}\n<div class=\"columns is-centered is-multiline is-vcentered is-variable is-8\">\n  {{ range $companies }}\n  {{ $logo := printf \"img/logos/%s\" .logo | relURL }}\n  <div class=\"column is-one-quarter\">\n    <a href=\"{{ .url }}\" target=\"_blank\">\n      <img src=\"{{ $logo }}\">\n    </a>\n  </div>\n  {{ end }}\n</div>\n"
  },
  {
    "path": "layouts/shortcodes/scalers-compact.html",
    "content": "{{ partial \"scalers.html\" . }}"
  },
  {
    "path": "layouts/shortcodes/supportedby-icons.html",
    "content": "{{ $companies := site.Params.supportedby }}\n<div class=\"columns is-centered is-multiline is-vcentered is-variable is-8\">\n  {{ range $companies }}\n  {{ $logo := printf \"img/logos/%s\" .logo | relURL }}\n  <div class=\"column is-one-quarter\">\n    <a href=\"{{ .url }}\" target=\"_blank\">\n      <img src=\"{{ $logo }}\">\n    </a>\n  </div>\n  {{ end }}\n</div>\n"
  },
  {
    "path": "layouts/shortcodes/troubleshooting.html",
    "content": "{{ $issues := where site.RegularPages \"Section\" \"troubleshooting\" }}\n\n{{ range $issues }}\n{{ $problem  := .Title | markdownify }}\n{{ $solution := .Content }}\n{{ $id       := .Title | urlize }}\n<div class=\"card is-collapsible has-mouse-icon\" x-data=\"{ open: false }\" id=\"{{ $id }}\">\n  <header class=\"card-header\" @click=\"open = !open\">\n    <p class=\"card-header-title title is-size-4 is-size-4-mobile\">\n      {{ $problem }}\n    </p>\n    <button class=\"copyBtn\" id=\"{{ $id }}\"><i class=\"fas fa-link\" style=\"color: #0c0d0d;\"></i></button>\n  </header>\n  <div class=\"card-content card-content-dropdown\" x-show=\"open\" id=\"{{ $id }}\">\n    <div class=\"content is-medium has-text-grey-dark\">\n      {{ $solution }}\n    </div>\n  </div>\n</div>\n{{ end }}\n"
  },
  {
    "path": "layouts/shortcodes/user-icons.html",
    "content": "{{ $users := site.Params.users }}\n<div class=\"columns is-centered is-multiline is-vcentered is-variable is-8\">\n  {{ range $users }}\n  {{ $logo := printf \"img/logos/%s\" .logo | relURL }}\n  <div class=\"column is-one-quarter\">\n    <a href=\"{{ .url }}\" target=\"_blank\">\n      <img src=\"{{ $logo }}\">\n    </a>\n  </div>\n  {{ end }}\n</div>"
  },
  {
    "path": "netlify.toml",
    "content": "[build]\npublish = \"public\"\ncommand = \"npm run build:preview\"\n\n[context.production]\ncommand = \"npm run build:production\"\n"
  },
  {
    "path": "package.json",
    "content": "{\n  \"name\": \"keda-docs\",\n  \"private\": true,\n  \"scripts\": {\n    \"build\": \"hugo --cleanDestinationDir -e dev -DFE\",\n    \"build:preview\": \"hugo --cleanDestinationDir --minify -e dev -DFE --baseURL \\\"${DEPLOY_PRIME_URL:-/}\\\"\",\n    \"build:production\": \"hugo --cleanDestinationDir --minify\",\n    \"check:links\": \"HTMLTEST_ARGS='--log-level 1 --skip-external' make --keep-going check-links\",\n    \"precheck:links\": \"npm run build\",\n    \"serve\": \"netlify dev -c \\\"hugo serve -DFE\\\" --framework hugo\",\n    \"serve:hugo\": \"hugo serve -DFE\"\n  },\n  \"devDependencies\": {\n    \"@docsearch/css\": \"4.6.2\",\n    \"@docsearch/js\": \"4.6.2\",\n    \"@fontsource/inria-sans\": \"5.2.8\",\n    \"@fontsource/roboto-mono\": \"5.2.8\",\n    \"@fortawesome/fontawesome-free\": \"7.2.0\",\n    \"alpinejs\": \"3.15.11\",\n    \"bulma\": \"0.8.2\",\n    \"hugo-extended\": \"0.160.1\",\n    \"lunr\": \"2.3.9\",\n    \"netlify-cli\": \"25.2.0\"\n  }\n}\n"
  },
  {
    "path": "static/_redirects",
    "content": "/concepts/*     /docs/concepts/:splat\n/concepts/overview     /docs/concepts\n/deploy/*     /docs/deploy/:splat\n/faq/*     /docs/faq/"
  },
  {
    "path": "static/img/keda-arch-new-source.excalidraw",
    "content": "{\n  \"type\": \"excalidraw\",\n  \"version\": 2,\n  \"source\": \"https://excalidraw.com\",\n  \"elements\": [\n    {\n      \"id\": \"bg\",\n      \"type\": \"rectangle\",\n      \"x\": -149.89991188942338,\n      \"y\": 177.6216165027413,\n      \"width\": 883.3515625000001,\n      \"height\": 691.20703125,\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"#e7f5ff\",\n      \"fillStyle\": \"hachure\",\n      \"strokeWidth\": 2,\n      \"roughness\": 1,\n      \"opacity\": 30,\n      \"angle\": 0,\n      \"seed\": 1837477438,\n      \"version\": 773,\n      \"versionNonce\": 2059255378,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"qs6l3Ff7lzQJs220D4VYv\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1774108999850,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"a0\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"bg-label\",\n      \"type\": \"text\",\n      \"x\": -100.05078125,\n      \"y\": 162.28515625,\n      \"width\": 183.5600128173828,\n      \"height\": 25,\n      \"text\": \"Kubernetes Cluster\",\n      \"fontSize\": 20,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 9001,\n      \"version\": 192,\n      \"versionNonce\": 1132167330,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473875,\n      \"index\": \"a1\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Kubernetes Cluster\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"eventsource-box\",\n      \"type\": \"rectangle\",\n      \"x\": 200,\n      \"y\": 99.87109375,\n      \"width\": 360,\n      \"height\": 64,\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1054254208,\n      \"version\": 9,\n      \"versionNonce\": 724676990,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"strokeStyle\": \"dashed\",\n      \"index\": \"a2\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"eventsource-label\",\n      \"type\": \"text\",\n      \"x\": 319.8125,\n      \"y\": 111.14453125,\n      \"width\": 126.25200653076172,\n      \"height\": 22.5,\n      \"text\": \"Event Sources\",\n      \"fontSize\": 18,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#343a40\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 102,\n      \"version\": 97,\n      \"versionNonce\": 1256423614,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332702446,\n      \"index\": \"a3\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Event Sources\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"eventsource-sub\",\n      \"type\": \"text\",\n      \"x\": 253.4296875,\n      \"y\": 143.296875,\n      \"width\": 249.8760223388672,\n      \"height\": 15,\n      \"text\": \"Kafka · RabbitMQ · Elasticsearch · SQS · ...\",\n      \"fontSize\": 12,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#868e96\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 103,\n      \"version\": 116,\n      \"versionNonce\": 1935761662,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"arrow-1\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332708497,\n      \"index\": \"a4\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Kafka · RabbitMQ · Elasticsearch · SQS · ...\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-1-label\",\n      \"type\": \"text\",\n      \"x\": 395.98828125,\n      \"y\": 178.23828125,\n      \"width\": 72.72200012207031,\n      \"height\": 16.25,\n      \"text\": \"Poll metrics\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#f08c00\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 202,\n      \"version\": 43,\n      \"versionNonce\": 1636887522,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"a6\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Poll metrics\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"keda-bg\",\n      \"type\": \"rectangle\",\n      \"x\": 99.66024179131637,\n      \"y\": 219.27977561057673,\n      \"width\": 575.3671875,\n      \"height\": 168.23437500000009,\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"#dbe4ff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 60,\n      \"angle\": 0,\n      \"seed\": 1703810176,\n      \"version\": 197,\n      \"versionNonce\": 770048638,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"Dg1JH1y9woiD2txdgGma3\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"a7\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"keda-bg-label\",\n      \"type\": \"text\",\n      \"x\": 352.74609375,\n      \"y\": 226.15234375,\n      \"width\": 49.06800079345703,\n      \"height\": 22.5,\n      \"text\": \"KEDA\",\n      \"fontSize\": 18,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#1864ab\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 301,\n      \"version\": 131,\n      \"versionNonce\": 1845317646,\n      \"isDeleted\": true,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"arrow-1\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1774109188209,\n      \"index\": \"a8\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"KEDA\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-1\",\n      \"type\": \"arrow\",\n      \"x\": 377.38294606562573,\n      \"y\": 220.15234375000003,\n      \"width\": 0.9117950872238794,\n      \"height\": 55.85546875000003,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          0.9117950872238794,\n          -55.85546875000003\n        ]\n      ],\n      \"strokeColor\": \"#f08c00\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 832471936,\n      \"version\": 389,\n      \"versionNonce\": 2001338322,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1774109188209,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"a8V\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": null,\n      \"endBinding\": {\n        \"elementId\": \"eventsource-sub\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.5001,\n          1\n        ]\n      },\n      \"moveMidPointsWithElement\": false\n    },\n    {\n      \"id\": \"operator-box\",\n      \"type\": \"rectangle\",\n      \"x\": 120,\n      \"y\": 251.87109375,\n      \"width\": 160,\n      \"height\": 72,\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 601326720,\n      \"version\": 6,\n      \"versionNonce\": 831913618,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1774108954716,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"a9\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"operator-label\",\n      \"type\": \"text\",\n      \"x\": 129.98828125,\n      \"y\": 264.23828125,\n      \"width\": 95.88600158691406,\n      \"height\": 17.5,\n      \"text\": \"keda-operator\",\n      \"fontSize\": 14,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#1864ab\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 311,\n      \"version\": 32,\n      \"versionNonce\": 340581218,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aA\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"keda-operator\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"operator-sub\",\n      \"type\": \"text\",\n      \"x\": 131.41734313964844,\n      \"y\": 286.36328125,\n      \"width\": 137.52200317382812,\n      \"height\": 27.5,\n      \"text\": \"Watches KEDA Resources\\nManages HPA lifecycle\",\n      \"fontSize\": 11,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 312,\n      \"version\": 112,\n      \"versionNonce\": 1719912910,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"QqNXFuLZrly8QpmmjaPyO\",\n          \"type\": \"arrow\"\n        },\n        {\n          \"id\": \"qs6l3Ff7lzQJs220D4VYv\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1774108954716,\n      \"index\": \"aB\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Watches KEDA Resources\\nManages HPA lifecycle\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"metrics-box\",\n      \"type\": \"rectangle\",\n      \"x\": 300,\n      \"y\": 251.87109375,\n      \"width\": 160,\n      \"height\": 72,\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 930280576,\n      \"version\": 4,\n      \"versionNonce\": 399346686,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aC\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"metrics-label\",\n      \"type\": \"text\",\n      \"x\": 307.98828125,\n      \"y\": 264.23828125,\n      \"width\": 141.3360137939453,\n      \"height\": 16.25,\n      \"text\": \"keda-metrics-apiserver\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#1864ab\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 321,\n      \"version\": 32,\n      \"versionNonce\": 628288226,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aD\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"keda-metrics-apiserver\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"metrics-sub\",\n      \"type\": \"text\",\n      \"x\": 311.7717819213867,\n      \"y\": 286.2265625,\n      \"width\": 135.2010040283203,\n      \"height\": 27.5,\n      \"text\": \"Exposes external metrics\\nto Kubernetes HPA\",\n      \"fontSize\": 11,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 322,\n      \"version\": 53,\n      \"versionNonce\": 660029090,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"o5AIWHv-1YltESqUftZiA\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332473876,\n      \"index\": \"aE\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Exposes external metrics\\nto Kubernetes HPA\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"webhooks-box\",\n      \"type\": \"rectangle\",\n      \"x\": 480,\n      \"y\": 251.87109375,\n      \"width\": 160,\n      \"height\": 72,\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 639657088,\n      \"version\": 4,\n      \"versionNonce\": 1142940862,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aF\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"webhooks-label\",\n      \"type\": \"text\",\n      \"x\": 488.11328125,\n      \"y\": 264.11328125,\n      \"width\": 146.9399871826172,\n      \"height\": 15,\n      \"text\": \"keda-admission-webhooks\",\n      \"fontSize\": 12,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#1864ab\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 331,\n      \"version\": 30,\n      \"versionNonce\": 1492851298,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aG\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"keda-admission-webhooks\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"webhooks-sub\",\n      \"type\": \"text\",\n      \"x\": 491.0558433532715,\n      \"y\": 287.37109375,\n      \"width\": 141.7570037841797,\n      \"height\": 27.5,\n      \"text\": \"Validates KEDA Resources\\nconfiguration on apply\",\n      \"fontSize\": 11,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 332,\n      \"version\": 127,\n      \"versionNonce\": 1012882446,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1774109005031,\n      \"index\": \"aH\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Validates KEDA Resources\\nconfiguration on apply\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-2-label\",\n      \"type\": \"text\",\n      \"x\": 208.01034545898438,\n      \"y\": 335.05078125,\n      \"width\": 103.23300170898438,\n      \"height\": 32.5,\n      \"text\": \"Create / update\\nHPA resource\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"right\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#f08c00\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 402,\n      \"version\": 146,\n      \"versionNonce\": 1423796706,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aJ\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Create / update\\nHPA resource\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"apiserver-box\",\n      \"type\": \"rectangle\",\n      \"x\": 240,\n      \"y\": 395.87109375,\n      \"width\": 280,\n      \"height\": 64,\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 366376064,\n      \"version\": 9,\n      \"versionNonce\": 1166054846,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"o5AIWHv-1YltESqUftZiA\",\n          \"type\": \"arrow\"\n        },\n        {\n          \"id\": \"arrow-3a\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aK\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"apiserver-label\",\n      \"type\": \"text\",\n      \"x\": 280.11328125,\n      \"y\": 415.98828125,\n      \"width\": 188.61500549316406,\n      \"height\": 21.25,\n      \"text\": \"Kubernetes API Server\",\n      \"fontSize\": 17,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#343a40\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 501,\n      \"version\": 32,\n      \"versionNonce\": 588897698,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aL\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Kubernetes API Server\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-3a\",\n      \"type\": \"arrow\",\n      \"x\": 380.028,\n      \"y\": 505.99609375,\n      \"width\": 0,\n      \"height\": 40.125,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          0,\n          -40.125\n        ]\n      ],\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 302125952,\n      \"version\": 106,\n      \"versionNonce\": 810073662,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"aM\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": {\n        \"elementId\": \"hpa-box\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.5001,\n          0\n        ]\n      },\n      \"endBinding\": {\n        \"elementId\": \"apiserver-box\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.5001,\n          1\n        ]\n      },\n      \"moveMidPointsWithElement\": false\n    },\n    {\n      \"id\": \"arrow-3a-label\",\n      \"type\": \"text\",\n      \"x\": 394.11328125,\n      \"y\": 474.11982046790916,\n      \"width\": 143.364013671875,\n      \"height\": 16.25,\n      \"text\": \"Query external metrics\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 602,\n      \"version\": 41,\n      \"versionNonce\": 554817890,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aN\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Query external metrics\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"hpa-box\",\n      \"x\": 240,\n      \"y\": 511.99609375,\n      \"type\": \"rectangle\",\n      \"width\": 280,\n      \"height\": 64,\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1813243008,\n      \"version\": 21,\n      \"versionNonce\": 209766078,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"arrow-3a\",\n          \"type\": \"arrow\"\n        },\n        {\n          \"id\": \"qs6l3Ff7lzQJs220D4VYv\",\n          \"type\": \"arrow\"\n        },\n        {\n          \"id\": \"QqNXFuLZrly8QpmmjaPyO\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aO\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"hpa-label\",\n      \"type\": \"text\",\n      \"x\": 276.74527740478516,\n      \"y\": 529.98828125,\n      \"width\": 203.96800231933594,\n      \"height\": 20,\n      \"text\": \"Horizontal Pod Autoscaler\",\n      \"fontSize\": 16,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#343a40\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 701,\n      \"version\": 30,\n      \"versionNonce\": 1578392866,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aP\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Horizontal Pod Autoscaler\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-4\",\n      \"type\": \"arrow\",\n      \"x\": 380,\n      \"y\": 575.87109375,\n      \"width\": 0,\n      \"height\": 52,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          0,\n          52\n        ]\n      ],\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1064543104,\n      \"version\": 5,\n      \"versionNonce\": 1739632446,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"aQ\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": null,\n      \"endBinding\": null\n    },\n    {\n      \"id\": \"arrow-4-label\",\n      \"type\": \"text\",\n      \"x\": 424.74609375,\n      \"y\": 595.76171875,\n      \"width\": 223.62599182128906,\n      \"height\": 16.25,\n      \"text\": \"Scale up / down (1 → N and N → 1)\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 802,\n      \"version\": 129,\n      \"versionNonce\": 663775458,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aR\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Scale up / down (1 → N and N → 1)\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"deployment-bg\",\n      \"type\": \"rectangle\",\n      \"x\": 200,\n      \"y\": 627.87109375,\n      \"width\": 360,\n      \"height\": 120,\n      \"strokeColor\": \"#495057\",\n      \"backgroundColor\": \"#f8f9fa\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 2032358528,\n      \"version\": 16,\n      \"versionNonce\": 198246930,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"qs6l3Ff7lzQJs220D4VYv\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1774108954716,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aS\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"deployment-label\",\n      \"type\": \"text\",\n      \"x\": 335.87890625,\n      \"y\": 639.00390625,\n      \"width\": 87.80799865722656,\n      \"height\": 20,\n      \"text\": \"Deployment\",\n      \"fontSize\": 16,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#343a40\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 901,\n      \"version\": 60,\n      \"versionNonce\": 2096376766,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332498707,\n      \"index\": \"aT\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Deployment\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"replicaset-box\",\n      \"type\": \"rectangle\",\n      \"x\": 260,\n      \"y\": 665.87109375,\n      \"width\": 240,\n      \"height\": 68,\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"#ebfbee\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 453768064,\n      \"version\": 5,\n      \"versionNonce\": 119021630,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"HjCxtbTJ1WaKIcEEZiiYh\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aU\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"replicaset-label\",\n      \"type\": \"text\",\n      \"x\": 346.328125,\n      \"y\": 692.2734375,\n      \"width\": 76.06500244140625,\n      \"height\": 18.75,\n      \"text\": \"ReplicaSet\",\n      \"fontSize\": 15,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 911,\n      \"version\": 94,\n      \"versionNonce\": 1825111970,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332491611,\n      \"index\": \"aV\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"ReplicaSet\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-5\",\n      \"type\": \"arrow\",\n      \"x\": 380,\n      \"y\": 747.87109375,\n      \"width\": 164.08227272727248,\n      \"height\": 38,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          -164.08227272727248,\n          38\n        ]\n      ],\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 108659584,\n      \"version\": 235,\n      \"versionNonce\": 1337814754,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332652477,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"aW\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": null,\n      \"endBinding\": {\n        \"elementId\": \"pod1-box\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.5001,\n          0\n        ]\n      },\n      \"moveMidPointsWithElement\": false\n    },\n    {\n      \"id\": \"arrow-5-label\",\n      \"type\": \"text\",\n      \"x\": 269,\n      \"y\": 772.87109375,\n      \"width\": 98.74800109863281,\n      \"height\": 16.25,\n      \"text\": \"Desired replicas\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1002,\n      \"version\": 231,\n      \"versionNonce\": 1695792162,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aX\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Desired replicas\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"pod1-box\",\n      \"type\": \"rectangle\",\n      \"x\": 140,\n      \"y\": 791.87109375,\n      \"width\": 100,\n      \"height\": 48,\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 314885248,\n      \"version\": 7,\n      \"versionNonce\": 766591650,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"arrow-5\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332652478,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aY\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"pod1-label\",\n      \"type\": \"text\",\n      \"x\": 165,\n      \"y\": 807.87109375,\n      \"width\": 37.79999923706055,\n      \"height\": 17.5,\n      \"text\": \"Pod 1\",\n      \"fontSize\": 14,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1102,\n      \"version\": 27,\n      \"versionNonce\": 1967908834,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"aZ\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Pod 1\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"pod2-box\",\n      \"type\": \"rectangle\",\n      \"x\": 330,\n      \"y\": 791.87109375,\n      \"width\": 100,\n      \"height\": 48,\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1454912640,\n      \"version\": 4,\n      \"versionNonce\": 1841191358,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"aa\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"pod2-label\",\n      \"type\": \"text\",\n      \"x\": 355,\n      \"y\": 807.87109375,\n      \"width\": 41.62200164794922,\n      \"height\": 17.5,\n      \"text\": \"Pod 2\",\n      \"fontSize\": 14,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1104,\n      \"version\": 27,\n      \"versionNonce\": 1829280674,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"ab\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Pod 2\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"podellipsis\",\n      \"type\": \"text\",\n      \"x\": 446,\n      \"y\": 807.87109375,\n      \"width\": 12,\n      \"height\": 25,\n      \"text\": \"···\",\n      \"fontSize\": 20,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1105,\n      \"version\": 27,\n      \"versionNonce\": 2054739810,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"ac\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"···\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"podn-box\",\n      \"type\": \"rectangle\",\n      \"x\": 520,\n      \"y\": 791.87109375,\n      \"width\": 100,\n      \"height\": 48,\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 717071488,\n      \"version\": 7,\n      \"versionNonce\": 1572244094,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [\n        {\n          \"id\": \"HjCxtbTJ1WaKIcEEZiiYh\",\n          \"type\": \"arrow\"\n        }\n      ],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"ad\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"podn-label\",\n      \"type\": \"text\",\n      \"x\": 545,\n      \"y\": 807.87109375,\n      \"width\": 40.66999816894531,\n      \"height\": 17.5,\n      \"text\": \"Pod N\",\n      \"fontSize\": 14,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1107,\n      \"version\": 27,\n      \"versionNonce\": 770415394,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"ae\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Pod N\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"scaledobject-box\",\n      \"type\": \"rectangle\",\n      \"x\": -139.2899307594651,\n      \"y\": 214.75261089568198,\n      \"width\": 209.99481430062707,\n      \"height\": 241.9639885457811,\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"#f8f0fc\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 397444224,\n      \"version\": 622,\n      \"versionNonce\": 1747681102,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1774108921491,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"af\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"scaledobject-label\",\n      \"type\": \"text\",\n      \"x\": -120.04029846191406,\n      \"y\": 235.83593750000006,\n      \"width\": 177.59922790527344,\n      \"height\": 12.382812499999991,\n      \"text\": \"Custom Resource Definitions (CRDs)\",\n      \"fontSize\": 9.906249999999993,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1201,\n      \"version\": 460,\n      \"versionNonce\": 902817506,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473876,\n      \"index\": \"ag\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Custom Resource Definitions (CRDs)\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"crd1-box\",\n      \"type\": \"rectangle\",\n      \"x\": -116.55859375,\n      \"y\": 272.84375,\n      \"width\": 160.16172963877017,\n      \"height\": 54.405311089650816,\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 1.5,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 934896768,\n      \"version\": 287,\n      \"versionNonce\": 2125880190,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"ah\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"crd1-label\",\n      \"type\": \"text\",\n      \"x\": -106.5703125,\n      \"y\": 283.328125,\n      \"width\": 81.54900360107422,\n      \"height\": 16.25,\n      \"text\": \"ScaledObject\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1211,\n      \"version\": 176,\n      \"versionNonce\": 448051874,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"ai\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"ScaledObject\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"crd1-sub\",\n      \"type\": \"text\",\n      \"x\": -106.69140625,\n      \"y\": 301.6953125,\n      \"width\": 126.72000885009766,\n      \"height\": 12.5,\n      \"text\": \"Deployment / StatefulSet\",\n      \"fontSize\": 10,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#868e96\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1212,\n      \"version\": 237,\n      \"versionNonce\": 2068387426,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"aj\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Deployment / StatefulSet\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"crd2-box\",\n      \"type\": \"rectangle\",\n      \"x\": -117.47187536703723,\n      \"y\": 332.6039267683359,\n      \"width\": 160,\n      \"height\": 52,\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 1.5,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1393181824,\n      \"version\": 411,\n      \"versionNonce\": 162587710,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419183,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"ak\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"crd2-label\",\n      \"type\": \"text\",\n      \"x\": -107.60468786703723,\n      \"y\": 343.4164267683359,\n      \"width\": 62.30899429321289,\n      \"height\": 16.25,\n      \"text\": \"ScaledJob\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1221,\n      \"version\": 502,\n      \"versionNonce\": 1213987362,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"al\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"ScaledJob\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"crd2-sub\",\n      \"type\": \"text\",\n      \"x\": -107.48359411703723,\n      \"y\": 361.0492392683359,\n      \"width\": 112.33000946044922,\n      \"height\": 12.5,\n      \"text\": \"Batch / Job workloads\",\n      \"fontSize\": 10,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#868e96\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1222,\n      \"version\": 440,\n      \"versionNonce\": 14444002,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"am\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Batch / Job workloads\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"crd3-box\",\n      \"type\": \"rectangle\",\n      \"x\": -116.71796911703723,\n      \"y\": 395.5375205183359,\n      \"width\": 160,\n      \"height\": 52,\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"#ffffff\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 1.5,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 933438592,\n      \"version\": 242,\n      \"versionNonce\": 1086792958,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419184,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"an\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"crd3-label\",\n      \"type\": \"text\",\n      \"x\": -106.65156286703723,\n      \"y\": 405.8578330183359,\n      \"width\": 128.62799072265625,\n      \"height\": 15,\n      \"text\": \"TriggerAuthentication\",\n      \"fontSize\": 12,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#862e9c\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1231,\n      \"version\": 270,\n      \"versionNonce\": 1842960802,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"ao\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"TriggerAuthentication\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"crd3-sub\",\n      \"type\": \"text\",\n      \"x\": -106.77274215835354,\n      \"y\": 423.95418596154525,\n      \"width\": 102.9100112915039,\n      \"height\": 12.5,\n      \"text\": \"Secrets / credentials\",\n      \"fontSize\": 10,\n      \"fontFamily\": 5,\n      \"textAlign\": \"center\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#868e96\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1232,\n      \"version\": 328,\n      \"versionNonce\": 1585567074,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"ap\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Secrets / credentials\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"arrow-metrics-back-label\",\n      \"type\": \"text\",\n      \"x\": 393.421875,\n      \"y\": 355.9140625,\n      \"width\": 79.89599609375,\n      \"height\": 15,\n      \"text\": \"Fetch metrics\",\n      \"fontSize\": 12,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1301,\n      \"version\": 259,\n      \"versionNonce\": 1680136482,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"as\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Fetch metrics\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"o5AIWHv-1YltESqUftZiA\",\n      \"type\": \"arrow\",\n      \"x\": 380.0259850132613,\n      \"y\": 389.87109375,\n      \"width\": 0.022045476656728624,\n      \"height\": 65.64453125000006,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          -0.022045476656728624,\n          -65.64453125000006\n        ]\n      ],\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1748185984,\n      \"version\": 358,\n      \"versionNonce\": 1376323810,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332454181,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"at\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": {\n        \"elementId\": \"apiserver-box\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.5001,\n          0\n        ]\n      },\n      \"endBinding\": {\n        \"elementId\": \"metrics-sub\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.5001,\n          1\n        ]\n      },\n      \"moveMidPointsWithElement\": false\n    },\n    {\n      \"id\": \"l-RzpLZG5U4qgeqgnbrn-\",\n      \"type\": \"text\",\n      \"x\": 93.02102152506507,\n      \"y\": 596.6302083333333,\n      \"width\": 223.15798950195312,\n      \"height\": 16.25,\n      \"text\": \"Scale up / down (0 → 1 and 1 → 0)\",\n      \"fontSize\": 13,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#e67700\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 840235999,\n      \"version\": 230,\n      \"versionNonce\": 238118114,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"au\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"Scale up / down (0 → 1 and 1 → 0)\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"qs6l3Ff7lzQJs220D4VYv\",\n      \"type\": \"arrow\",\n      \"x\": 164.0091789830321,\n      \"y\": 319.01953125,\n      \"width\": 215.8908210169679,\n      \"height\": 302.8515625,\n      \"angle\": 0,\n      \"strokeColor\": \"#f08c00\",\n      \"backgroundColor\": \"#ffec99\",\n      \"fillStyle\": \"hachure\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"groupIds\": [],\n      \"frameId\": null,\n      \"index\": \"aw\",\n      \"roundness\": null,\n      \"seed\": 2090619776,\n      \"version\": 1555,\n      \"versionNonce\": 1976792786,\n      \"isDeleted\": false,\n      \"boundElements\": [],\n      \"updated\": 1774108956031,\n      \"link\": null,\n      \"locked\": false,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          0,\n          267.91212661074564\n        ],\n        [\n          215.8908210169679,\n          267.91212661074564\n        ],\n        [\n          215.8908210169679,\n          302.8515625\n        ]\n      ],\n      \"startBinding\": {\n        \"elementId\": \"operator-sub\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.23699360895861515,\n          1.1875\n        ]\n      },\n      \"endBinding\": {\n        \"elementId\": \"deployment-bg\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.4997222222222222,\n          -0.05\n        ]\n      },\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"elbowed\": true,\n      \"fixedSegments\": [\n        {\n          \"index\": 2,\n          \"start\": [\n            0,\n            267.91212661074564\n          ],\n          \"end\": [\n            215.8908210169679,\n            267.91212661074564\n          ]\n        }\n      ],\n      \"startIsSpecial\": false,\n      \"endIsSpecial\": false\n    },\n    {\n      \"id\": \"yHEaIHsM4npDrCzsg6leR\",\n      \"type\": \"arrow\",\n      \"x\": 383.04077697349504,\n      \"y\": 756.9544270833333,\n      \"width\": 0,\n      \"height\": 44,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          0,\n          44\n        ]\n      ],\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 862921600,\n      \"version\": 7,\n      \"versionNonce\": 1290817214,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419184,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"ax\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": null,\n      \"endBinding\": null\n    },\n    {\n      \"id\": \"HjCxtbTJ1WaKIcEEZiiYh\",\n      \"type\": \"arrow\",\n      \"x\": 393.2207808813599,\n      \"y\": 751.2421874999999,\n      \"width\": 136.22970413643128,\n      \"height\": 34.74519853968479,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          136.22970413643128,\n          34.74519853968479\n        ]\n      ],\n      \"strokeColor\": \"#2f9e44\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 735818880,\n      \"version\": 783,\n      \"versionNonce\": 968083198,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419184,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"ay\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": null,\n      \"endBinding\": {\n        \"elementId\": \"podn-box\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.7658586849103699,\n          0.2341413150896301\n        ]\n      }\n    },\n    {\n      \"id\": \"Dg1JH1y9woiD2txdgGma3\",\n      \"type\": \"arrow\",\n      \"x\": 70.99159888805241,\n      \"y\": 283.642578125,\n      \"width\": 29.172549153263958,\n      \"height\": 1.2489801951611526,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          29.172549153263958,\n          1.2489801951611526\n        ]\n      ],\n      \"strokeColor\": \"#1971c2\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 2,\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 888328854,\n      \"version\": 386,\n      \"versionNonce\": 1742616382,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419184,\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"index\": \"b02\",\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"startBinding\": null,\n      \"endBinding\": {\n        \"elementId\": \"keda-bg\",\n        \"mode\": \"inside\",\n        \"fixedPoint\": [\n          0.0008757994215650332,\n          0.3900022377090555\n        ]\n      },\n      \"moveMidPointsWithElement\": false\n    },\n    {\n      \"id\": \"trigger-block\",\n      \"type\": \"rectangle\",\n      \"x\": -27.054389394302518,\n      \"y\": 258.08128586240383,\n      \"width\": 64.2333970397126,\n      \"height\": 21.304687500000018,\n      \"strokeColor\": \"#e67700\",\n      \"backgroundColor\": \"#fff4e6\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 1,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 495940736,\n      \"version\": 641,\n      \"versionNonce\": 2144378750,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419184,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"b10\",\n      \"strokeStyle\": \"dashed\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"trigger-block-label\",\n      \"type\": \"text\",\n      \"x\": -19.00167088642003,\n      \"y\": 262.42592769166896,\n      \"width\": 50.83985137939453,\n      \"height\": 13.596450985423036,\n      \"text\": \"trigger(s)\",\n      \"fontSize\": 10.87716078833843,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#e67700\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 9902,\n      \"version\": 628,\n      \"versionNonce\": 641104034,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"b11\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"trigger(s)\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"2MyjQA5BDQ7l3ZhNLjfFd\",\n      \"type\": \"rectangle\",\n      \"x\": 215.56120816561463,\n      \"y\": 241.99358053992373,\n      \"width\": 52.905088521114635,\n      \"height\": 18.812459625908406,\n      \"strokeColor\": \"#e67700\",\n      \"backgroundColor\": \"#fff4e6\",\n      \"fillStyle\": \"solid\",\n      \"strokeWidth\": 1,\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1033884800,\n      \"version\": 892,\n      \"versionNonce\": 233920510,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332419184,\n      \"roundness\": {\n        \"type\": 3\n      },\n      \"index\": \"b17\",\n      \"strokeStyle\": \"dashed\",\n      \"frameId\": null,\n      \"link\": null,\n      \"locked\": false\n    },\n    {\n      \"id\": \"oM53NNNCpiF1kfQHe89eJ\",\n      \"type\": \"text\",\n      \"x\": 223.46968414952528,\n      \"y\": 244.3893088205931,\n      \"width\": 36.536685943603516,\n      \"height\": 13.673909505208304,\n      \"text\": \"scalers\",\n      \"fontSize\": 10.939127604166643,\n      \"fontFamily\": 5,\n      \"textAlign\": \"left\",\n      \"verticalAlign\": \"top\",\n      \"strokeColor\": \"#e67700\",\n      \"backgroundColor\": \"transparent\",\n      \"fillStyle\": \"solid\",\n      \"roughness\": 1,\n      \"opacity\": 100,\n      \"angle\": 0,\n      \"seed\": 1753481190,\n      \"version\": 710,\n      \"versionNonce\": 1810044002,\n      \"isDeleted\": false,\n      \"groupIds\": [],\n      \"boundElements\": [],\n      \"updated\": 1773332473877,\n      \"index\": \"b18\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"frameId\": null,\n      \"roundness\": null,\n      \"link\": null,\n      \"locked\": false,\n      \"containerId\": null,\n      \"originalText\": \"scalers\",\n      \"autoResize\": true,\n      \"lineHeight\": 1.25\n    },\n    {\n      \"id\": \"QqNXFuLZrly8QpmmjaPyO\",\n      \"type\": \"arrow\",\n      \"x\": 190.33854776924233,\n      \"y\": 319.01953125,\n      \"width\": 43.661452230757675,\n      \"height\": 224.87656249999998,\n      \"angle\": 0,\n      \"strokeColor\": \"#f08c00\",\n      \"backgroundColor\": \"#ffec99\",\n      \"fillStyle\": \"hachure\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"groupIds\": [],\n      \"frameId\": null,\n      \"index\": \"b19\",\n      \"roundness\": null,\n      \"seed\": 1979466210,\n      \"version\": 205,\n      \"versionNonce\": 731151634,\n      \"isDeleted\": false,\n      \"boundElements\": [],\n      \"updated\": 1774108926232,\n      \"link\": null,\n      \"locked\": false,\n      \"points\": [\n        [\n          0,\n          0\n        ],\n        [\n          0,\n          224.87656249999998\n        ],\n        [\n          43.661452230757675,\n          224.87656249999998\n        ]\n      ],\n      \"startBinding\": {\n        \"elementId\": \"operator-sub\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          0.4284492900755477,\n          1.1875\n        ]\n      },\n      \"endBinding\": {\n        \"elementId\": \"hpa-box\",\n        \"mode\": \"orbit\",\n        \"fixedPoint\": [\n          -0.02142857142857143,\n          0.49843749999999964\n        ]\n      },\n      \"startArrowhead\": null,\n      \"endArrowhead\": \"arrow\",\n      \"elbowed\": true,\n      \"fixedSegments\": null,\n      \"startIsSpecial\": null,\n      \"endIsSpecial\": null\n    },\n    {\n      \"id\": \"ZwiT9E6IrQnINiKxd8tMT\",\n      \"type\": \"image\",\n      \"x\": 311.8969631105767,\n      \"y\": 170.03737075137064,\n      \"width\": 131.55859375000003,\n      \"height\": 131.55859375000003,\n      \"angle\": 0,\n      \"strokeColor\": \"transparent\",\n      \"backgroundColor\": \"#ffec99\",\n      \"fillStyle\": \"hachure\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"groupIds\": [],\n      \"frameId\": null,\n      \"index\": \"b1A\",\n      \"roundness\": null,\n      \"seed\": 417457422,\n      \"version\": 211,\n      \"versionNonce\": 1397626510,\n      \"isDeleted\": true,\n      \"boundElements\": null,\n      \"updated\": 1774109137781,\n      \"link\": null,\n      \"locked\": false,\n      \"status\": \"saved\",\n      \"fileId\": \"65e649e8b30930959214e72e6503ca4f59ec309b\",\n      \"scale\": [\n        1,\n        1\n      ],\n      \"crop\": null\n    },\n    {\n      \"id\": \"op_WEJxPCGy8DycY9YV08\",\n      \"type\": \"image\",\n      \"x\": 337.4829006105767,\n      \"y\": 224.05636489199568,\n      \"width\": 86.30859374999986,\n      \"height\": 36.46538085937494,\n      \"angle\": 0,\n      \"strokeColor\": \"transparent\",\n      \"backgroundColor\": \"#ffec99\",\n      \"fillStyle\": \"hachure\",\n      \"strokeWidth\": 2,\n      \"strokeStyle\": \"solid\",\n      \"roughness\": 0,\n      \"opacity\": 100,\n      \"groupIds\": [],\n      \"frameId\": null,\n      \"index\": \"b1B\",\n      \"roundness\": null,\n      \"seed\": 313019150,\n      \"version\": 329,\n      \"versionNonce\": 2074691598,\n      \"isDeleted\": false,\n      \"boundElements\": null,\n      \"updated\": 1774109206950,\n      \"link\": null,\n      \"locked\": false,\n      \"status\": \"saved\",\n      \"fileId\": \"7dc7962598139e9d368782eedcc19347aae45b5c\",\n      \"scale\": [\n        1,\n        1\n      ],\n      \"crop\": null\n    }\n  ],\n  \"appState\": {\n    \"gridSize\": 20,\n    \"gridStep\": 5,\n    \"gridModeEnabled\": false,\n    \"viewBackgroundColor\": \"#ffffff\",\n    \"lockedMultiSelections\": {}\n  },\n  \"files\": {\n    \"7dc7962598139e9d368782eedcc19347aae45b5c\": {\n      \"mimeType\": \"image/png\",\n      \"id\": \"7dc7962598139e9d368782eedcc19347aae45b5c\",\n      \"dataURL\": \"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAFSCAYAAAAKBbuLAAAAAXNSR0IArs4c6QAAAERlWElmTU0AKgAAAAgAAYdpAAQAAAABAAAAGgAAAAAAA6ABAAMAAAABAAEAAKACAAQAAAABAAADIKADAAQAAAABAAABUgAAAAAOTt+bAABAAElEQVR4Ae29a5Ac2XXnd29mdVWjGw00AIIcPLjqEcGxPLC44IC2wo6w2ROxYVsRVgiUYtarR5gN20H5wwyJMRlhW/YagP3Bu7ESB+RMbHjl8A4kWtJaQ3Ig0WsxZJHTQ1KWuCJAkBZmxeGIaEoAmhSIQePRXa/Me31uVlWj311VXY+8mb8keyorK/Pec3830V3/PPecoxQbBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQCDXBHSuRy+D/8Cz89MmMNOp4WCDuSsvHrqYGnt2aMiJM9cnA1M8s8Nmhn75lU8fOTd0IzYwIHX37wY2cmgHBFL4+yA395ywD6yac7MXFdTc1QuHkn33ng0CvhN46rlbZ5S2k+2MwwTBRe7/dkhxTicECp2cnMVzE/Fh9dm0jM0qOyu2XEyLPTu1I4xKr1mtTuy0neFer08Pt//Ne0/b/bu5pXzSDYE0/j7Izz1nlWk+ogtipeQLm5vCBavUVa3snNLq+4EJZhEn3dzZXDNMAslDBGVfUPLHuZ0tiM2PyXmp/TvYzhg4J30Eci9A0jcl2bHoqeduvix/rL0XH1nySGXn7mIkEBgKgUn5yjatRH0o+eVmtD3bFCcNYaLt6w1RUrl69cLjC0OxkE4hsA0BebDxwjanrPlYz8hqhue5p9dg4e2OCCBAdoSPizcj4MSH/JGe2exzT45fQHx4MlOYCYHhEmgIE6unG6KkpE4+e+uqDezvO0HyjZcOzQ7XPHqHQIPAU8/Nz4gA6fjBYHMp9Tk4QqBXBBAgvSJJO8sEnvrozXPi2p1ZPuDljr145cUjz3tpOkZDAAJDJ5AsPbX6hBMksnxLvCH2klLB6yasXOJJ8tCnJ8cG2LNdDd7qj4kX5AL3blf0uGgDAsEGxzgEga4JuKcrIj66+wXXda+9vdAqNSvig/WuvcVKaxDIM4HJhkfYvhzEpbvOQyweklN5BsLYB08g+fus1FSXPWcioUyXY+eyPhBAgPQBal6bbPxysy/7PH5t1VUbVj/k8xiwHQIQSDsBPSMeklfFMyJi5NYLJ87MT6XdYuzLAoEuvR+toYsXpLXLKwR2SgABslOCXJ8QOHHmxglZYuC1+JCBzMWF6tO4mLmpIQCBAREQz4g6E8T2+vufu/Va8wn1gLqmmzwR2KH3o4Vqknu0hYLXnRJAgOyUINcrJz6COHjNcxQLJjQfQnx4PouYDwFPCUherWn3EEc8Itfl54yroeTpUDA7lQR26P1YHlOv2llukJ2cEkCA5HTiezXsFeLD5z+WTnyI5+Po1V5xoR0IQAACXRKYkutekFiR6y6hB0KkS4pctkygR96PVntTeEFaKHjdCQEEyE7o5fxa94cxjAK37Mpn8SHFYNVpxEfOb2aGD4H0EZh0CT0QIumbGP8s6rXXotft+UcUi3dOAAGyc4a5bKEhPrJR5fzyS4cv5XISGTQEIOADgZYQ+SZPnn2YrnTZ2GPvR2twU2Rxa6HgtVsCCJBuyeX8Oh2XXk3y3PvMQdvzFBr0eQKxHQK5IjDlYkTki983P/Ds/HSuRs5gd0CgP94KoxUZsXYwK1wqVZGAAIFOCbgc9o2AyU6vTNP5Umjw00fOpckibIEABCCwHQH34EeKG0rGrJsvEx+yHa18f94n70cC1X0HQAjn+/7a6egRIDslmLPr3R+9RkEtnweeVDk/7fMIsB0CEMg7AT2TxIdIxqy8k2D8mxHoj/ej1Vus+9t+qx9es0kAAZLNee3LqFxqSN/Fhys0aMLa830BRKMQgAAEBkvAJQB5wdUQoZjhYMGnvTeXQU1snOqnnc4L0qgB1s9eaDurBBAgWZ3ZHo+r6cp9ocfNDrQ5Jz4oNDhQ5HQGAQgMgID7IijFDL9JYPAAYHvQRbI0b0BVy4OY6uge3BKpNBEBksppSZdRDfHhfZXzhbigKTSYrlsLayAAgd4RmJT4kFeJDekdUF9bCkzRLctz3rEBbHoG79sAMGewCwRIBie1l0NquFet154P4dEsNHhorpdsaAsCEIBA+gjomTAqyZKsGyfSZxsW9ZvAIL0frbEEsTnb2ucVAu0SQIC0SyqH52WkyrmiynkOb16GDIEcE3CZsoI4kExZ8zM5xpDLoQ/W+9FCjBekRYLX9gkgQNpnlasznUvV/QGTQQ/IjdsvvJoq5/1CS7sQgECaCcjvbvuyJA/x3YOdZsapsm0Y3o8WgMCYmdY+rxBohwACpB1KOTvH/RILI/uqDNt78UGhwZzdvAwXAhBYS+CMiJBXky+naz/hfaYIDMf70UQoQe/cY5m6nfo+GARI3xH71UFDfJRecy58vyxfa62r9XHo4tqjvIcABCCQQwKnGnEh1z1/qJTDmWtzyMmX/wFlvtrEpMmmANrkYw5DYDUBBMhqHrl/J4WtXs6G+DhyOveTCQAIQAACTQKNuJDSNwlOz+YtMVTvRwspXpAWCV7bIIAAaQNSXk5pVDlXp3wer6v1ceVFxIfPc4jtEIBA3wgksX2IkL7xHUrDKfB+tMY9KQ8xZ1pveIXAVgQQIFvRydFnDfGhZ3wecqvQoM9jwHYIQAACfSYgXxID0vT2GfIgm0+F9+PRgD/2aJc9CGxOAAGyOZvcfNJI1ei3+JDJmqPKeW5uWQYKAQjsjAAiZGf8UnN1irwfLSZTpH9uoeB1KwIIkK3o5OCzrFQ5l1ofVDnPwf3KECEAgZ4RQIT0DOXwGkqZ96MJwlKYcHi3hDc9I0C8mareG3ry2VsS72Ff7n3LA22xWeX86NWB9kpnEIAABPwngAjxeA5dvS413MxXm9HDC7IZGY4vE0CALKPI144LQpSsKL6LD5k0/fzVC4iPfN29jBYCEOghAURID2EOsqkgNs7TkMrUylbZDw+SBX35RwAB4t+c7dhiJz6yUuWcWh87vh1oAAIQgEBThFAnxJdbIfF+KD2TVnu1UtMfeHZ+Oq32YdfwCSBAhj8HA7XABaxlQnxoex7xMdBbh84gAIFsE5ikWKE/E9z0fqTa4FgTC5LqCRqycQiQIU/AILt34sP9gZE+U+mybZ+FVDn/9JFz7Z/PmRCAAAQgsB0BV6xQx6VXtzuPz4dLIO3ejxYdvCAtErxuRAABshGVDB5riQ//q5yrSxQazOANypAgAIFUEHBfGptFaVNhD0asJ+CD96NltdGWuiAtGLyuIoAAWYUju2+CuPiC7+LDFRo0YfV0dmeJkUEAAhBIAwE9Qy2HNMzDeht88X6ssPxUw+YVR9iFgBBAgOTgNshSlfOrFx5fyMGUMUQIQAACQyZgX3AJS4ZsBN2vIeCT96Nluo82t2zntX8ECv1rmpbTQOCp5269IHbMpMGWHdiwEBc0hQY3AmiDOUl3OLvRRxzzn4Ash7nq/yj6PwKr1GwvegmsmvTdU9wLDs02XMKSV2X57vt58NNDqjtoKvEkxHZmB00M6VI9I7afv3rh0NyQDKDbFBJAgKRwUnplUrPK+ZletTekdlqFBueG1H+qu21mAruYaiMxDgJ9JvDNFw8/3esuXApREfeTNrAnrNUfFDHovAGTve4n5e1NBXHpZbHxQym3MxfmNTwJcid6uDW9IKc9NB2T+0QAAdInsMNutik+3B8Or7fA6g9dodCg13OI8RDwkcA3Xjo027T7Ust+9wQ6iNW0UvZn5Zi85kKQnHJ/T0h7LrM9xM1f70cLmpZYkOtSOJhl1C0ieX8lBiSDd0Cj+I/1XnxIlfPTK74EZHCmGBIEIOATAbeExH0Rv/Li4Q/Jzz5JjCGeAXtRxrDg0zg6t9XFg8xPdX4dV/SKQAbiKCYDUzzTKx604z8BBIj/c7hqBC5oUNLeZSCPuz7NE7dVU8sbCEAgZQQuv3Q4SQvuxIh7YGJ7FIuSsmE6cyZ1nIWHWikk24ZJDfGnZ9o4Nd2nWP0xVxIg3UZi3aAIIEAGRXoA/TjxkYkq5/JEEfExgBuGLiAAgZ4RcL+zXCyKCfXjTa9Iz9pOQ0MSeSD1QeZn0mBL3mwIYuuSyWRhwwuShVns0RgQID0COexm3FMFl7FE7PD86YITH0cIVBv2DUX/EIBAVwQay7SOnM6mEHFLsXiC3dWN0eVFjSXV6lSXl6fvMvGCpM8oLBoGAQTIMKj3uE/3ByGMSq9Js1M9bnqgzblCg4iPgSKnMwhAoE8EVgsRdalP3Qy6WXnQVczK0/hBs+uqv1jbs11dmN6LJvGkpXdyBmkZAmSQtPvUlxMfvueud+IjLlSf7hMimoUABCAwFAINIXL4Q5LR72n3e24oRvS0Uz3TfCrf01ZpbD0Bx9ktfVv/ie9HMieqfJ+QodiPABkK9t516qqc+y4+hIYUGqw+TXq+3t0XtAQBCKSLgMvoJ0Hr71fank+XZZ1bk8Gn8p1DGMAVGeY8hRdkADdQyrtAgKR8grYyz4kPybwys9U5HnzWLDRIbnAP5goTIQCBHRK48ukj50xo3u+zN8Q9lecL5A5vhG0uz673ozVwvCAtEnl9RYB4OvNPffTmueyIj6MZWJbg6Y2E2RCAwMAJXJXiqo0lp0kNkYH335sO+QLZG44bt5Jh70drwFMs5WuhyOcrAsTDeU+ePFmdgcA0LVVRER8e3oKYDAEI7JCAW3LaSLqhT++wqWFdzjKaPpHPvvejAS4HIqtPd0g2mkWAeDaPDbd3FgpCUWjQs1sPcyEAgT4QcPVD3JIsaXqhD833uUm8IP0AnJcv5m4pH16QftxBfrSJAPFjnhIrXaFBKXAlcR/ebxcoNOj9HDIACECgRwScJ1hEiI9ZsvCC9OgeaDWTF+9Ha7x5EVut8fL6iAAC5BGLVO+tqHKeaju3N84VGjz8/PbncQYEIACB/BBoxYX4F5yOF6SXd2nevpA7L0jj4WovKdKWDwQQIB7M0grxMemBuVuZeIlCg1vh4TMIQCDPBFxciAtO90yE4AXp0U2bN+9HC1sQUx29xSJPrwiQlM92o8p54JZdeS0+3B9UE1Z9DbZM+V2CeRCAQFYI+ChCrLIfzgr/YY4jb96PR6z1zIkz81OP3rOXBwIIkBTPckN8ZKfKOYUGU3yzYRoEIJAaAi0RIgbNpcaoLQxhGc0WcNr86OSzt045jm2enrnTgthkILNn5qalrwNCgPQV784a13Hp1WxUOTenER87uxe4GgIQyBcB9ztTAtM/JKP2IjsWy2h2dn/K3/oXdtaC71fjBfF9Bju1HwHSKbEBne+qnGfgaUizyjm1PgZ029ANBCCQIQIuMD2w2okQDzb3BfK610uFhwW5WVV+alj9p6XfwJiZtNiCHf0ngADpP+OOe3DiIwNVzpX7w0mhwY6nnwsgAAEILBP4xkuHZuWNF5kDg7g0s2w4Ox0QIJNYAsvqjyFiO7htPD8VAZKyCWx4PfRMyszqwhx9uvmHs4truQQCEIAABFoEJHX5Bdm/1Hqf4tePpdi2VJqG92PVtEwGpnhm1RHeZJYAAiSzUzvUgT1PocGh8qdzCEAgYwSaWQQXUj6sKWo6dDpDeD9WEcMLsgpHlt8gQLI8u0MZW1Jo0D2tY4MABCAAgR4RcEHpPsSDEIze/oTj/diQ1SRL+TbkkrmDCJDMTekwB+TEx5HTw7SAviEAAQhklUBzWWvKH/DoU1nl3/tx4f3YhClL+TYBk6XDCJAszeYQx+IKDSI+hjgBdA0BCOSCgCzFOi8DTfNSrElX0yIXk7GDQeL92BLeVJPPlifxod8EECB+z18qrHfiIy5Un06FMRgBAQhAIMMEGjWVdKqzYlltfzbDU9CjoeH92BokfLbm4/+nCBD/53DYI1hw4oNCg8OeBvqHAATyQsAl+XAPftI7XpZhbTU3eD+2orP8GV6QZRTZ3EGAZHNeBzWqZqHBx9O8HGBQLOgHAhCAwMAIaJVqL8gk2bC2uhV4ur8VndZnVtkPt/Z5zR4BBEj25nRgIzKhEc8HVc4HBpyOIAABCDQJuIB0q9RsWoEEBi/IRnOD92MjKhsfc3XRPvDs/PTGn3LUdwIIEN9ncGj269OIj6HBp2MIQAACKrTaBaSnctNGEweyZmYaVb7xfqzBsuXbWMNrS0Aef4gA8Xjyhme6Pk2hweHRp2cIQAACjkCavSBWqxONL9zMVYtAs8r3VOs9r9sTwAuyPSNfzyj4ajh2D43ABcTH0Niv6/jEmfmpQqSm1n3AgaEQiAqVqyRkGAr63HYqsSC/qZSdTiOAMCo5uy6l0bZB25SIsVhnpL6FLP5TIg0GtBltHbfZAXVHNwMigAAZEOhsdJMUGkx1+sdscG5/FIExM0brs+1fwZn9JFCIRp+W9mf72QdtQ2AlAfdA6Knnbr0gxyZXHk/Dvg3sCbEDASIQmt6P1M1Rd/eJEx8DFSGn3MO2qxcOzXVnL1elkQBLsNI4K6m1SX8rtaZhGAQgAIH8EriYxqFbqz+YRrsGbVPi/bBZ8X606A3OA+J6DGLDg7YW+oy8IkAyMpEDGsZZ1vQOiDTdQAACEGiTgGQk/M02Tx3oafIVdXqgHaa0s2x5P4YFWc84L8iweqff3hNAgPSeaZZbnAziEk8hsjzDjA0CEPCOgMtImNbChHmvB5JN78dw/ongBRkO9371igDpF9nstnsm739Qsju1jAwCEPCVgMRb/H4abQ/i0MWB5HbD+9HLqdcSC3I9I3E0veTiZ1sIED/nbahW6zhwAY9sEIAABCCQEgImsOkM9tZmKiWIBm4G3o+eI59sCrqeN0yDgyeAABk8c+97dOt6m9VcvR8LA4AABCCQBQLNwrBzaRtLngPRffV+TOxK8VdDCebHC5K2f+Xd2ZPiu6y7AXHVoAjYF/glMCjW9AMBCECgHQJ2tp2zBnmOPLCaGmR/aenLV+/HyfcW1S9Oj6cF40Z24AXZiIqHxxAgHk5aSkzml0BKJgIzIAABCDQIBK+nkMRUCm3qu0m+ej9+5acn+s5mxx1kLqXxjol42QACxMtpS4nRVktaXtLipWQ2MAMCEMg5ARPGV9OIIG9/J3z2fpw8VlTfeKuaxttopU2TLANficPPfQSIn/OWGqt1bF9OjTEYAgEIQCDHBJpxIKkjUIjytQzLV+/HuV9qJJh6sGRTdw+tN8hSEmA9FK+OIEC8mq70GSvre6dPPnvrVPoswyIIQAAC+SMgXx1n0zZqo/MjQBJvj6wOSNscbGfPz/zULnV4f5ic9ubN+nanp+HzKbwgaZiG7m1AgHTPjiubBKxWpOXlboAABCCQAgJa2bkUmLHahByl4vWxWJ7LevXxn9uTzNmtt+PVc5fqd3hBUj092xiHANkGEB+3RWDqqY/ePNfWmZwEAQhAAAL9I6DV9/vXOC1vRaAR66JntjonjZ+5rFet1LvzXgkQNfWBZ+en08gUm7YngADZnhFntEMgyc1NQHo7qDgHAhCAQL8IaKPTF4hu1Y/1a7xpatdH74dbdvUL02PLGC9/t7a878NOrPGC+DBPG9mIANmICse6ITAZxJalWN2Q4xoIQAACPSKglV7oUVM9a8YqPdWzxlLakK/ej49I2t2W98OhfVA2KSW8sVkuDhUvyMZs0n4UAZL2GfLLvlP8IvBrwrAWAhCAAAR2TsBX74cLPl+5fcePAPSVJiu8IKtwePMGAeLNVPlhqFV4QfyYKayEAASySOAbLx2azeK40jwmX70f5365kXZ3Jdv5Oz4FoTcsd16QE2dunFg5DvbTTwABkv458spCyYh14qnnbp3xymiMhQAEIAABCHRJwEfvx8n3FpUrOrh28ysL1iPrg1h/7NE79nwggADxYZb8s1EqpF9f/2jFv3FgMQQgAAEIQGBTAr56Pz7RTLu7cmCe1P9YafKKfT3TmIsVh9hNNQEESKqnx1vjJCC9SEC6t9OH4RCAAAQg0A4BH70fLu7jiSMj64b3oCxlLD3efJwLj3Hv2HQEyI4R0sDGBNzTCNZkbsyGoxCAAAQg4DsBH70fLuOVy3y10eZbCt71Y8ALsp5Jeo8gQNI7N95bpuMAL4j3s8gAIAABCEBgIwI+PnF3RQdd7Y+NNt9S8G40hsCYmY2Ocyx9BBAg6ZuTzFjkMlM89dz8TGYGxEAgAAEIQAACQsBX78fKooNrJ9LHFLxrx6CSosjEoK7jksIDCJAUTkq2TLIvEJCerRllNBCAQHoJEIg7mLnRsX15MD31rpeP/PTuVUUH17bsYwretWOQ95OBKZKJcwMwaTuEAEnbjGTPHglIL53N3rAYEQQgAIH0EShEaip9VmXLIldw13n4fRqVW3blll9ttfmagnfdmPCCrEOSxgMIkDTOSvZsOsNTuexNKiOCAAQg0A4B+bK+0M55vpzjY+Xtj2+Qdnclb79T8K4cSbLvHnzOrDvKgVQRQICkajqya4yP7urszgYjgwAEskrABGY6dWPT9lups6lLg3z0friig9PvG91yxLc8rIC+5YCUojDhNoCG/TECZNgz0Lv+53rXVO9bcu7qk8/eOtX7lmkRAhCAAAQgMBgCPno/fmWTtLsrib15M1r5Ngv7UyTBSfc0IkDSPT9tWmcvmrD6fjk51W5uqxUB6W3OKKdBAAIQ6IaAtfqD3VzX12usTvXfpnbH7qP3wxUdPHmsuO0Qb72dOQEiY7bEn24788M7AQEyPPY96tlevPLikdNXLzy+oLT9VI8a7VczU2Sn6Bda2oUABCCglHibT6SNQ2D11bTZ1I09Pno/Nis6uHb8mQlAXz0wvCCreaTqHQIkVdPRqTEN8dG66sqnj5yT/bnW+1S+Jtkp5qdSaRtGQQACEPCYQDPl+aTHQ0it6T56P9zSq82KDq4F/eaNLHpAxAei7IfXjpX36SCAAEnHPHRhxWrx8agBff7Rfir3JDuFpUJ6KqcGoyAAAZ8JhFFpOo32f+OlQ7NptKsTm3zzfkzsCtRWRQfXjj0LVdDXjsm9d/GnTjxu9BnHhksAATJc/l32vpn4UOrKi4cuWqVmu2x4UJed4hfCoFDTDwQgkBcCEmf3wRSO1fv4Dx+9H67mhxMh7WyX36q1c5q35/gmHr0F3aHh7d2dHTbK6f0ksLn4aPUa2tR7QZTR/lWRbfHlFQIQgEAaCWirptNmlzwQ8z7+w7cvsG7Zlat63u72YMm0e6qX5+EFSee0IUDSOS+bWLW9+HAXNtzd9uImjaTlsASH3TqTFmOwAwIQgIDPBFz8h3hATqRtDFrZubTZ1Ik9Pno/2g08b3HIYAre1tCWX402H15+w04qCBRSYQVGtEGgPfHRasiEwXmJtZhpvU/p61n5o3kxyeCVUgPTbpYJgouFKPVL7tKOsWf2RYWK9097ewaDhgZKIIhHT7mQ2/Rt2usihM77IU/Qvdlc0UGXereTLZspeNcS0DMnzsyfv3rh0NzaT3g/HAIIkOFw77DXzsSHa9z9I3vqozfPK6vPdtjZIE+XgPSiC0g/PchOs9RX85fpXJbGxFggAIFuCNif7eaqfl/jcwreRiE7O91vRr1sv52ig2v7y2gK3rXDVEFs3Pchvm+sIzOcAyzBGg73DnrtXHy0GjdB7YLsL7Tep/NVzxCQns6ZwSoIQMAPAs30u+IBSd/mt1fQr0J20+8bbavo4Nq7JKspeNeOU3JiOS/I1PrjHBkGAQTIMKi33Wf34sN10VzadL7t7oZ0ouTpJi3vkNjTLQQg4D+BxvKr9I1DguKv+rrEtuH9UFPpo7q5RR//uT2bf7jFJ1lNwbvRkJtekI0+4tiACSBABgy8g+4uuQrnHZy/4alXXjzsvCBzG36YkoMucLL5yz4lFmEGBCAAAX8IaGs/lkZrrbZX02hXezYNw/vRfQyPi/tot+jgyvFnPQXvyrE29vWppsdw/UccGSgBBMhAcbfXmXtqZMLqjsVHqzdp7/nWfnpf7Qv8Ukjv7GAZBCCQTgInztw4kcbsVw1awevppLa1VcPzfuitDdvkU1fvo1vvx6078SatZvbwZGCKZzI7Oo8GhgBJ32TNxYXq0710W19+6fAlea4ym76hrrJIAtJLaQ6YX2UsbyAAAQikgUAQ61R6PxwbE6b+784mU+iX96OTooNrBzz/du4EiCSL0x/jgefaO2Hw7xEgg2e+ZY8iFOZ6KT5andnQeOAFUWfc07yWzbxCAAIQgMDmBBoBtXpm8zOG+on8LfMv5alv3g+37OoXpse6nujv3Kx3fa3HF+IFScHkIUBSMAmDMOHqhaOyFjf1xQmVjgMC0gdxQ9AHBCDgPYHAmJn0DsLOpte2rSwbhvdjK3u2/swVHXRLsLrd8hSAvoqR1R9e9Z43AyfQ/V07cFPpcKcEXHFCaWNhp+3083pZATt98tlbp/rZB21DAAIQ8J1AsoRElpKkdxz+xX8Mz/vR3Sw+cWSk46KDa3u6/N3a2kN5eT9F8pvhTjUCZLj8B9p74g7X9lMD7bSLziSgkoD0LrhxCQQgkB8CzSKuk2kdsQkrl9Jq2+Z2+eX9+MTPd5d2tzX+3Ho/WgCUX/O9bHZGdhAgGZnIdofhR3FCNUWWinZnlPMgAIG8EUh57Iebjkv9iGXs5zz75v04+d5iV0UHVzJ882a08m0e9/GCDHHWESBDhD+Mrht/FHT6A9KtPkvF0mHcIfQJAQiknYCO7cspt9HD9Lt+PQ3/RJdFB1feNzlMwbty+M19v+Z9gwF4ewgB4u3UdW/4lRcPXXS1RrpvYTBXBjEV0gdDml4gAAFfCLgYORcrl2Z7Tai9Wn41HO+H5LzscnNFB138x063XKbgXQ9t6gPPzk+vP8yRfhNAgPSbcErb18oDL4hSp/jFkNIbCLMgAIGBE3CB5xIjl3bvhyy/8if9bqMexDAedomM7GJzGa9c5qtebDlNwbsOXazxgqyDMoADCJABQE5jF9946dCsPH+ZTaNtK20yOvVLDVaayz4EIACBvhGQYq1OfKQ28LwxcP37fQPQh4ab8YYDZtq998MVHXS1P3qxEYTeoOg8ijzs7MUd1VkbCJDOeGXqbBvq0x4MaOqpj94854GdmAgBCECgbwSeeu7WGWn8VN866E3DCz5lvxpeKuPuvR87KTq4dopznIJ3LQqFF2Qdkr4fQID0HXF6O2i4ydNfnFBJrnsC0tN7H2EZBCDQXwInztw4IT2c7W8vvWjdepX9ajjej+45f1wCz3dSdHBlz3g/VtJQynlB+J6xmkm/3yFA+k045e2bsOYyYi2k3MzJIDYe/PFNOUXMgwAEvCPgntIHcfCqGD6ZduNNmP46Uy2Gw/N+tCzo7NUtu3LB573aSMG7niTfM9Yz6ecRBEg/6XrQdpKW14PihPJ8YoY1mh7cUJgIAQj0lICOS058TPW00T405jIrXr1w9Gofmu5Lk755P879cm/153du1PvC1e9G9QxekMHNIAJkcKxT21OzOOFcag1sGmbVMDKVpJ0K9kEAAlkl8NRzN192S0N8GJ/V+lM+2Ols9M370Yuig2vn5mG5+0D4tW1l6T1ekMHNJgJkcKxT21OzOOH51BrYNEzST55oBmKm3VTsgwAEILAjAk58OM/vjhoZ3MULrr7U4LrbWU++eT9+pUdpd1dS+8Zb1ZVv2V8mgBdkGUWfdxAgfQbsS/Puj4c8D5n1wF6pkH69t75oDwaNiRCAQH4INB60eCM+RCcR+7H13dm9t8HFfZw8Vty6+S4+fbDUvU1ddOfVJYExM14Z7KmxCBBPJ64fZodWp94LIuOWgMzS2X6MnzYhAAEIDJtAM+34C8O2o5P+TRBc7OT8YZ47HO+HLKTrcutV0cG13b95kxiQtUyW3yeZN3nQucyjTzsIkD6B9bFZV5xQ7L7kge1nmmkpPTAVEyEAAQi0RyBZdmW1Zw9Y7EVfKp/7Fvvhll71qujgyjvw1tvxyrfsrycw2RSq6z/hSM8IIEB6hjIbDZlQu7S8qd90HHj1hDD1QDEQAhAYKgHPYj6WWZkw8MFzntg7HO/HMqqOdly9j14WHVzZ+TwCZCWOjffxgmzMpYdHESA9hJmFpppPsi6kfSzi0J5+6rn5mbTbiX0QgAAEtiLgnsqffPbWNz0KOF8xHLwfK2D0dPcjP727Z0UH1xpGCt61RDZ8L8u9R09t+AkHe0IAAdITjNlqxIRV90RrIf2jsgSkp3+SsBACENiEgFtKKjFt112Gv01OSfVhr7wfjdjByVQDbRrnll394vR430wlBW+7aK1nyyHbHVc6zkOApGMeUmVFIy2v8sGtPsU6zVTdOhgDAQi0ScAFm0uFc/F8pL/C+SZDuuBP7Mf8lIzhzCbjSN3hfgWetwZKCt4WiW1fp1hpsS2jrk9AgHSNLtsXXnnx8AUZ4VzqRykBm1QuTf0sYSAEINAk4H5fvf+5W68p74LNV03hQtNTvupgWt/4VFzOFR10qXf7uZGCtxO6eEE6odXJuQiQTmjl7FxtlScB6fblnE0Nw4UABDwk0PB62G+6GDYPzX9kstT9aHrKHx1L6V7jAZWeSal568zqR9HBtZ2QgnctkS3f4wXZEk/3HyJAumeX+Ssvv3T4kvWgOKH7Y/6BZ+enMz8hDBACEPCSgPv9JMUFrze9Hl7EIWwBeu7Kp4+c2+LzVH3kk/dj+n2jfSk6uHJCSMG7kkZ7+1bZD7d3Jmd1QgAB0gmtHJ7rSXFCZTRekBzengwZAqkm4ISHW24lv59eE0OnUm1sm8YFVp9u89ShnzZ474c8stvB9vGf27ODq9u7lBS87XFaeRYPOVfS6N0+AqR3LDPZUqM4ob3oweCmmhWEPTAVEyEAgSwTWCk83JeX7IzVXmwWrPViSIP3fshsd7m5rFf9KDq41pzL362tPcT7NgjEmliQNjB1dAoCpCNc+TzZm1SLSeGgJNtJPieKUUMAAkMl4DLmtDwe2RIeCVYJPK95ERforPXJ++GKDrq6H4PYHpTNILrJXB94QXo/pQiQ3jPNXItJqkVtz3swMCkcZKmQ7sFEYSIEskLA1fKQ+I4X5OeuUvblDAqPZKokKclpXwLPncG+eT+cCBnE9p2b9UF0k8k+jDbEgvRwZgdzx/fQYJoaDgET1Fxa3oXh9N5Rr6cISO+IFydDAAIdEpDK5aeaouN6s5bHGWnC9+DyrShccElJtjohTZ8N3vvR/ejdsqtfmB7rvoEOr5y/E3d4Bac/IqBnGvfWoyPsdU+g0P2lXJknAu7JlywvEPd7+oO9JWOF84K8P0/zw1ghAIH+EHBfOMLInrCB/Fj9Qefh2FmocX/s7Fer4vm4GheqPnjAlxE0vB8yUx5srujgoLwfDgdZsHZ2UzQ9a6d31gpXOwIIEO6DtglcefHQRXnqd1YumGr7oiGcaLVySyLONIspDsGCwXXpvhwVonTPx+BoZK8nnwJ+h0m/F15PyVR1QmmbeDGc0HDjka+w0yqWRxqy4/7jXvK2xQXj1dKr5Al1bGd8mKcnjoz0vejgSg7U/1hJo9v9xAtyPlma3m0TXJcQQIBwI3REwKVgbKaU7Oi6IZwsFdKvX/RpzXI3jAJjZozWThSyZZNAHr/zdjyTPfudlCiNRHh0bEM2L9AiPo5e9WlsPnk/PvHz/U+7u3LuHpTz5LtbOfLe7uMF6Q1PYkB6wzE3rbgnsvIrbNaDAUtAepGAdA8mChMhAIE0ErAXndc7jZZtZlPDE6ZnNvs8TcdPvrfY96KDa8dLCt61RLp9r0/JA84sx3x1C6aj6xAgHeHiZEfAhsaTVIzOVXrjBLMGAQhAAALtE3BxH1dePHK6/SvScaZPtRrO/dLgv7+Sgrdn9+lkYIpnetZaThtCgOR04ncy7IZL3ovihErHAV6QnUw210IAAnkjMCdB50/7Nmjn/ZD1itM+2P0zP7VrIEUH17IgBe9aIjt4n9QdwwuyA4IKAbITejm+tlmQaiHtCNwfJFccLO12Yh8EIACBFBCQYoPmQz7Gzvni/XAZrz7+c4ON/WjdV6TgbZHoyStekB1iRIDsEGBeL0/+QGn7KT/Gb19gvaYfM4WVEIDA0Ag48fG0b0HnjpZP3o9fnB4faNrdlXcTKXhX0ujBvtUf7kEruW0CAZLbqd/5wJvFCed23lLfW+BJRd8R0wEEIOA3Af28j+LDMffJ+zHIooMr78fLb9VWvmW/NwSmWGHRPUgESPfscn9lw02vz3sBwmpJyzs/5YWtGAkBCEBgoAT0ad8yXrXw+OT9cEuvBll0sMXIvT5YMivfst8zApY0+F2yRIB0CY7LGgTcHy2XMcUHHjpOfxV3HzhiIwQgkCUC/ooPNwu+eD8O7w8HWnRw7R365s1o7SHe94YAXpAuOSJAugTHZY8ISH1gL9LyuoD0k8/eOvXIcvYgAAEI5JmA3+LDJ+/HuV+eHOqNduttBEj/JgAvSDdsESDdUOOaVQQ8Kk6opNAxAemrZo83EIBAPgn4LT7cnPni/RhG0cG19zQB6GuJ9PT9lBPDPW0xB40VcjBGhjgAAjbUp2WJ0/UBdLXTLqaaBYTO7bQhrocABCDgIYEFWTZ7+vJLhy55aPuyye4Ln1F2evlAinc+MaS0uyuR/MZzB1a+TcX+b/zhQ/XP/vBBKmzZqRFNMTy703bydD0ekDzNdh/HevXCoTlp/kIfu+hd00kBIQLSeweUliAAAU8IJKl2L7902Gvx4Vj74v1wRQefODLiye0xODNdVfbfmV0cXId97skt8cYL0hlkBEhnvDh7CwImrLqMWAtbnJKWjyaD2FIhPS2zgR0QgMAgCMz5WudjLRyfYj8+8tMTa83nvRD49c/fV06EZGnzRRSnhTkCJC0zkQE7/CpOqE7xtCIDNx1DgAAEtiXgMhXKA6L3+1rnY+0ArfLjAdKviPhw2a/YVhNw8Shf+Hp59cEMvHNeENL9tz+RCJD2WXFmGwSufPrIOTltro1Th36K0aTlHfokYAAEINBnAvZiXKhKhfPHffBOb8vCFX6TZCIntj1xyCe4eh/DKjo45KFv2/25387ErbjhOIPYUBdkQzLrDyJA1jPhyI4JeFKcUCnJ333rzI6HSwMQgAAE0kng+SsvHjmdFfHRQOxHytOP/PTuoRUdTOet2LDKVWS//N0sV2XXM3hB2rsDESDtceKsDgi44oRWqdkOLhnmqVIh/frkMA2gbwhAAAI9JrAQWP30lRcPX+hxu0Ntznk/xICpoRrRRudu2dUvTo+3cWb+Tvm1z93P/KDxgrQ3xQiQ9jhxVocEQuuNF0QC0osEpHc4v5wOAQikk4B7+CPxHo+7+kzptHAnVvnh/fh4CtLu7oRyv651cR9v3qz3q/kUtYsXpJ3JQIC0Q4lzOibQ+ONnL3Z84VAu0DMEpA8FPJ1CAAK9JfD8N188nJl4j5VofPF+uKKD0+8bXWk6+0LAZbz6jYzU/GhnQgNjZto5L8/nIEDyPPt9HrsJA5eW14uN9HleTBNGQgACGxBoZLky78/akqvVQ/XD++EyX7GtJ/C7s0sqV9XYk3pjLO9efyc8OoIAecSCvR4TSIoTauuFCHHp85pP2HpMgeYgAAEI9JGA/I6VwoKZSbG7EanBej9kEVuXm/N8nDxW7PLq7F6WtaKDbc7UZGCKJLnZAhYCZAs4fLRzAiaouSDIhZ23NIgW7AsEpA+CM31AAAI7JdCI9dCPN1Of77S5lF8/SO+HPI7qciP2Y2Nwv/GHDzNXdHDjka45ihdkDZDVbxEgq3nwrscEmukfvfCCyNAlIL10tscIaA4CEIBALwnMyZKrDzViPQ7N9bLhNLY1WO9H9wRc1iuKDq7n55Zd/c7s4voP8nFEvlOMnsrHUDsfJQKkc2Zc0SGB5rrkuQ4vG9bpZ06cuXFiWJ3TLwQgAIFNCCwoWW7lKprLkqtLm5yTwcOD9H50h88VHXR1P9jWE/j1z2c/7e76Ua88kv77d6W1g9xHgAySdo77kid2z/syfB0HpOX1ZbKwEwK5IGAvutS6brlVtooKbj15Pnk/nAhhW03AFR2c/XZl9cH8vZOCx0n9mvyNfJsR8y9mG0B83BsC7omdW7Pcm9b624oLSD/57C3cpv3FTOsQgMC2BJzwkDiPzFUz33bgzRPS//TYLbvC+7HxfP6zHKXd3ZhA62j67+OWpYN8RYAMknbO+7Kh8cYLYrUiID3n9yvDh8CQCCwotVJ4ZD/OYyPOTz1364wcn9roszQd+whpdzecDld08PJ3axt+lsODeEE2mHQEyAZQONQfAlcvHL3q/rD2p/WetzpFCr2eM6VBCEBgcwJzzRiPpscjn8LD4WlmI0x9QpAnjoyon/mpXZvPaI4/yVPRwXam2Sr74XbOy9M5CJA8zXYKxtosTihP+DzYrD574sz8lAeWYiIEIOAvgUsuq5Uk68hdjMdmU9Z8+DO52edpOf6Jn9+TFlNSZYfLepWrooNt0HdLuz/w7Px0G6fm5hQESG6mOh0DbRYn/FQ6rNneiiC2BKRvj4kzIACBzgjMyenPN+I7Dn8oX1mttgaVeD+kfsLWZw3/05PvLVJ0cINpcEUHXd0PtvUEYk0syEoqCJCVNNgfCAG/ihOqUzy1GMhtQScQyDQB8XLIElR1wYTm/Ym348XDF5IHMpkedeeD88X7ce6XUu+g6Rx+D6743dmlfBYdbIMdXpDVkAqr3/IOAv0n4NJISlo6CUi3L/e/t533YHRi5+M7b4kWIACBnBG4JON9XTwdlxAb28984v2I0+/9cHEfFB1cP59u2RWZr9ZzWXnEaONiQWZXHsvrPh6QvM78kMd95cVDF5tPBIdsSVvdTz310Zvn2jqTkyAAgbwSWLDui4UUCwysflq8HFp+XGwHno4274jBej9ktrrYXL2Pj/8csR8boSPwfCMqa4/pGWJLG0zwgKy9N3g/MAJa6eclM8RrA+twJx3JmmR5OidfJB5f2EkzXAsBCGSCwJx8fZ3T2r6ubDBnwvhqI8tfJsY2lEEM3vshC2K62H5xelxRdHA9OFd00KXeZdueQBCbs3LW6e3PzPYZCBD54yFfgmfTMs3yK9GtE87F9o2XDs0+9dzNi1bpKR8GHMSjp8TOiz7Yio0Q6BuBHfzOlN9vJ8Suyb7Z1oOGRVjMtprRykpqXPV99z4wQXLc/d5y79l6S2Cw3o/ubHfLrn5heqy7izN+FUuvOpngxAtyPu/LMuXvARsEIAABCEAAAhDIEwEpN3tO5OXsbHD84DuD0X375IHs6IgpVYtBYHfVld2lIj0eBnoisHbf33ln+Nj/+d8d/PWRgkaBbHCb/BefuvOPv/1XtevG2gUV6HtGhfeDeu1hrVBcLFWDpcp4paqqpdri0mI0PrVknrz2ZPzKcWVlDkTzy4JsttwRIAYkd1POgCEAAQhAAAK5JrD88HV6elpVHyvqejnQ8dg9XQ/KgYmUHom1DrUS7SHfjgOl/8l/uf8fID42vmf++Gpl9spbtflY6XIQqEpo5VXF1XoY1mwQ15Wq13dHY9FoFJnCRGQPqifNKxs3xdEcEUCA5GiyGSoEIAABCEAAAhs/cI+rgQiTccFTUdaId0S2MIj10z85evA9hwofhNt6AtW6rVx4deGrKlRLgVVlK+JDhIiIj6CmRuq1YhxFtbAel0v1+E6tavZWj5nZa+L1wPuxHmbOjiBAcjbhDBcCEIAABCAAASFw7ZVlT0iLh60vybFRpQNl3Y8sKTK/+p/ufbb1Oa+rCfzhN8qvzb8d35VFVBWrTUV0WzUypqZNXLPVQl18SfWxQi0ej+uJ92Pizdmm+ju/uiHe5Y4AAiR3U86AIQABCEAAAhBYSyAsGatHxmxQEPERWivrr8x///f3/1v7J4KfXHsu75W6v2QWzv+LB1+1KigLsbIxqhIEUUWFUU3FYa0U1aPxqBaVSxNx6W5k91bvmdmDt5vej7MiRNbpP7DmiAACJEeTzVAhAAEIQAACEGgSOP7M8lqskV3Ghkt77Ygxpm5KJrKyE5n4P/63d30UXhsT+MLXK18OjVmygSlro0V86Iogq+lYll/pSDDWo3rT+3F7cclMvPlgrfdjmf/GPXA0ywQk6wMbBCAAAQhAAAIQyCOBWVU6MG3VrXlVKFkbVSXsvLgoamSk/pn/dv/Pj5f0E91SufPA3KxGtqzM9i2sdAe4wHe5QrtXY408KNZBZJQsCJNs0OKY2VUMSkffEe7dvtX+nfE3t+O5T756/8/E0iVZfrXoXk2sK2GxWJH4mWo9COuBHq+X71TjpckHZu++stQ7EO/HK88YlUSgk/mqf7PjR8sIED/mCSshAAEIQAACEOgJAff9vvnwfVZ2D76hikf32PvV2Mj35lhHJcmDFQX/2a/98JXIjHwh0PVdQVgYNTYohbEtWW2LIgpG3I8JTKjdgi1lxAEQulVbjXVFUml32dTWseUDrZ1Hi1Cc2Ai0lLaUzFuuPbFvRFk7IodLUquspLXaJSaPSavjH/r3xn78f/gHe//dVivDeP2d15b+H6VMsvRK20JFcohVlS1UdaxqEjxTj6JqVB8P4sV31M27Fo+Zy3dFhh0/KQLEWYv4GMacpa1PBEjaZgR7IAABCEAAAhDoJwGnPhKBMHtw2p7cp+z83Tl7oBiaQml3bE05WIyL0chIFIRxpIOwqK1EVktQehQXrJQIMSPaBAXxTYjiCELxUoSiPsRjYRKvhRIh0dI3jUGInthkk8xRDaEiqX6NEzHSlBM1ytiiKBEROkFJcnM58RFLOmDRIkq/b2pkqLVInPfjla8tfkdEkyt9XlZBXDFaV7SKa5VA1cMRKyl3x2MzXzXV90R2Yq9YfVh+kpofm4DgcO4IIEByN+UMGAIQgAAEIACBFoGJw7P23p2jtlgoJF6QkeJ4PLpU1qo4op2fw9SllIUKYylMGEmdi5ookoKogTCMdGhEpBRiLTrCLZkS4RFETc/H9l+vCnJ+6+zAxlI6wzlBrOiOQEppiKdFPB8icEZjHceBHHDiQzwk4e4xsWKI29nPLPye2CK1PsJyrK1oDlUV50+tFupasV6NylEQ23IYL1bqZu+1KTPr3E3HWwbj/WiRyPvr9v9C8k6I8UMAAhCAAAQgkD0C7on8OSXF0JU++cQxM/9gTjsvSEWpSI3tUuGSPNwvVEVbFG01COKCqUla2bBQlzLfBVEJ4gEJjKzLcl4MJ0CkbKGoFVdLxG1bB37YUOt6JOeLwHE1RwJxoVgTiR9E5I30akR8SNOj0kqkrKzwkiVdssyrIK6V4tS7CvsbfQz+v9++Xvvm1e/VfihjFY+HeD0k9a6sO6uKx6Zm66P1eOxBNB7uj1S9EsePHTWjsjAL78fg58mHHhEgPswSNkIAAhCAAAQg0EMCTieIAHCbLMOaOCzlB+Vp/R15e0DNSylCFYVq1C5JXEg4Io6OYiUqxIVQJIJ4KZRbcSULspxHYkQEgxyJRXIUauKfSFpc8R9ZRbXBZuO6tCIfyHVOgIjQ0GFYCKIoKog/pRAqK8JDPnXLrmQdlizvKkinxdioUQmM37jRDfrp5SFXdPBTf/Dgj8SOsgikpOiguGoqsR6pRrVKvSTJwypxKYqXovje3djuPf6GnVBPNiE7S/B+9HI+fG8LAeL7DGI/BCAAAQhAAAKdEnBfjLV4QBpekGtKTR93bos31J25MRXJF+hQws6jkVEzMvrQFHUhqIkbpC6uipL8yAHJUCXfqAsVHdZ2KYkKkfVYje/akg2q4QUZdSbVNrRLh+5DkTnyf3ethK6LphFRI+4OqakxIqJEipLEKpTsV+JUGRGNU5Ij0r2N3jUZHtyw0T4f/Nq16p9e/avaDwRbQ3wEqhIbLYHnUnRQi2NIqp6PVsdFUlVM1Xk/bl22s3eF7yuJiOqzdTTvGwEEiG8zhr0QgAAEIAABCPSAgHsiL1EVToSo82pWnVXq+JPmZFHZiiSWvR/O2WhvwexeLMWLewIp8b0QTI6HOqrKMqtIItfH7rkFSPqhlq9SkQgJ+RreMEqa2yN78rL5tiSV/PaoePSBHi+L9CiJGIpFw4SidOqqLqJEwkmUlNRQoTZGsmBJbQ2l63/3x0bGN2+zf58478cLr95/TZadLYpfZlFGuiQxL+VYan/YuFpVxdGaeEEivUdH939UNQfUZcl8dVIyX50XASJc8X70b3I8bRkB4unEYTYEIAABCEAAAjsl0BQh6mwjUFo8IZfVK7L/jD55a8pWbih977G3dPQjCb9QpTiqlpoB4FLwe0mcEiJM1A/FjSFbKAEd8UQzBqTahl0lCZAol/S98UDvrWq9FC+G4YiUQhyJXC7euiqIJ8S5QSQAXkLTxSdizBPvHnHSZuDbFy9Xv3xrQRSY0WVZMFaRkiRVEUay5szUjHg/xqTquZaig0EcmKUfRvZyWYoOTosEOydcRVuxQWAtAQTIWiK8hwAEIAABCEAgRwSasQnnWi6LN5KxJ0LktgiRffckI9ZJVbn7hq4sTiXLtKqPFbV6y512LPm/24skiF2JY6OTLVos6HcVQl0vi4dlcsyWlqSBIApKpbG4Gts4lHLskhnLiQ8pQajV1MHCwAsQ3l8yC//zb9/7qoxrSRJ3VcRNIwJE3B1KIvRFfJRGKlFN2dgUJuL7PyrbA+++Z9RdKTooXiXlvErb+ILcCWz5I4AAyd+cM2IIQAACEIAABNYRSLwhclS+NLu4hXPPuEf39vK1k41H+Lf/Vl6flEPyc1tiRmTvwYPLWr1bdtRJSZY15XY62iqLb+h7f/Okruy+EeyV9UwjE1JwpLLLyJInSbwrP43aH869knyNP/yOcLKjDnpw8v/19cqXZIFZWUJekrofRup+SHR8TZII18RCif0oReXFQrx/b8XEi0vm8pzzfjzjYmtEhDTQ9cAMmsgYAQRIxiaU4UAAAhCAAAQg0C2BpjfEfXM+J6X2Glvj9dx089v0eTl6VmJGZHPi5K7b6WaTsuDiYTl+8I0gGh+zo9EPjcSWWKl9bl25QwlHf7TJQixX4PDIgcKRRwf7v3fjR/H1X//8/X8l2bjKkmW44jwgsVVVyRdclQTE9VItjCq2GJXq3zfzd/fYA/tc1qtrTfGR2Ndi2H9j6cErAggQr6YLYyEAAQhAAAIQGAAB+eK8/PReduRt8kTf9Xx2Zfc7+IL9hlbPyNf1fWV7rFS089XD6lBSXHxl87IvaXpFjCTpf0eLeteaT/v69jNfevhlWQJWkZRclVA7AWJEeEjshy7WJEFX3eyqReXavbjyjveZvTeUubwo1h4X74doK+G3AzZ9HRaNp4BAM5gqBZZgAgQgAAEIQAACEEgfAfki7b5M9/LHDTIJfLfqzZO29INjyZf1ljNFSg6K6EiiP1xtdOnYVVs3wcG9gVQsGcz2N+L9+OyflL8jkkIyXqmyRJtXTDAilc+DarkW1WPJuxvHu6KxhYl4NHrLHHRpIdJeVgAAIM9JREFUjI+7pWtOrbFBYGsCCJCt+fApBCAAAQhAAAIQ6DGB1d6BqmTaOiQ97JP/SY1CXYqrEt5dD0SDBJLyNvF+SAaqoFgYnAfk7Gfufj6J/RDPhyThEuEhRrnMV3FYKxbjqFSI4/L9KH77HXXjBNTstZXCY/X4egyP5jJAgCVYGZhEhgABCEAAAhCAgMcEXEYtCWaPa1JbpDCm46IUO3ReD6tl5ZORguNB8AtPj71nUCP8/+bqV771vfpN6U8qosRL1uglWQVWrteiqtGjtaD+oK7M/vruQiWOo6MN74dbp4b3Y1BT5H0/eEC8n0IGAAEIQAACEICAlwSuKX3yCcmkdeyYqktNkXiXVABxVdYLSpRHkHhAgoLsGBNIofWBfGdzRQc/den+H0u8h8R8SNyHLL8ST0ylHgc1q6J6KTJRLP+tFKL4h1IxvvSDN/B+eHnzDdfogdzMwx0ivUMAAhCAAAQgAIH0EnA1ROIlWehUC7QEmutEc8jSK6Oksl8k5UACHf7UT5R+fBAj+NpfVP/fb36vNu+qncv6r3IQiJtDsl7pUNLuysIwU4qi0XBc4j7+2ow+dtRc+3uSoZfYj0FMTab6QIBkajoZDAQgAAEIQAAC3hCQLFhJDZGWwXv2qMjFfcTNIHTZD1RBflQwVlRjrdP69eq8H5+8dP8rSeyHBJ1LCUQRH0bERyjiI6pbNVKviecj8X6MvyvxfqjfPSlB5y41sduI/Whw4L/bEUCAbEeIzyEAAQhAAAIQgEBvCTRy/Eq6Wldh3VVEj3ZrHUuCWxtVXO1zHUoMiNTbSLJfiSAJD+0vHO2tCetb++Ll6pdvvW0XbBCWpQhixRRjCT4X70cc15R4P0ajKNodVSJ5NaNRxVz7nng/DrrYD8no9Sht8fqGOQKBNQQQIGuA8BYCEIAABCAAAQj0l0CSqVar27PLxUbicqDH6w91HASBOEBk6ZX8JEHoEg5SMGFppL8ZsO4vmYX/6bfffl1ps6StCA/xgOi6iA8T1wLJfBXH9agW1uNyaSK+U6tK5isJCZmQqufHz7fS7rZe+4uO1jNBAAGSiWlkEBCAAAQgAAEIeEXgnLN2Wn6eVGZfqPdWF7QEogfFSHwNSfrdKAgkDkS+1UtwSBi8Y09/a4D8yz8v/5EKgsXQqkVjQ8l+JfU/RlQ5Fk9ItVCvxVqWX1XHovG4bsYXl8y1239r1PS0wfvh5pGtUwIIkE6JcT4EIAABCEAAAhDoEYFWDRBXBcRIDRA7IlmwtBMfzeVX8nr4YNDX+A9XdPCffP7+1601ZZf5ShaDNZdehTUVFOqluBiN7x6LSvtjc1uWXh08/qRRB2+vTLuL96NH90NemkGA5GWmGScEIAABCEAAAqklEI9pvcul4JUo9KQGiMR/GB1KXl4TfvDJUl/jP37rSw+/LOu+ygKnbCTlbqCDaiwVz3XBBZ+P1M2uKHooHo+3xftROtAsOnj8maboIPA8tTdVig1DgKR4cjANAhCAAAQgAIGMEmjVAFHNGiDV+9rcW9LiAGnU/5DlV4EyyRKsI+8M9/eLwg3xfnz2T8rfsYEqaxEfRmI/Gml345qtRfXYxFEc74p2F/ZI6l3xfkiKLNLu9ms28tMuAiQ/c81IIQABCEAAAhBIFYGTamUNkCgIJQVvzXlBJABdKqDLj5YaIEcmC/v6Zfb/+Jm7nxehI0uvpPCgiI+iiquBVDzXEnguWbCiUiGOy8UoCTzfWz1mZq9J1qvlDe/HMgp2OiJQ6OhsToYABCAAAQhAAAIQ6CmBqPK2rL/aLQuulI6NVDyXVytLsKQCodQCjIP9E8GBnnbYbOzb12vf/Pb1aN5VO5fUv+UwlLofRlcDqfuhgli8H8VI26WoJHoonpiyEwdEfBx2aXdXipB+WEabWSeAByTrM8z4IAABCEAAAhBIE4Hl1LutGiBKHZAAdEl25QoQSgosVwMklCAMGzgPSBhOTgQ9X4JVk6KDF159+KVYAs9F70gSYFl+FQcSfB5Uq1J0UFZeRWNRPSrf3x272I+91ct4P9J0F3luCwLE8wnEfAhAAAIQgAAEfCLQXMHUqgEi4eWT41IDpKR1aWRXkoLXuGogEguiXSFCY4KDe3ufgvcr16p/evX75XkJNCknHhAXfC7Lr+phXCtJ5qs4knVX9UbmKxf7cfmwq/mB98OnOy3NtiJA0jw72AYBCEAAAhCAQPYInDsvXpDpZFzvWgx15GqASAFCI1XQ43ojCL2RCUs8IOIQKRZ6W4SwFtnKC6/ef13bYFFCypdUqMqieCpSgqSq4notqFcl+1W1XilE8f0fleOk6OC1aWI/sncnDm1ECJChoadjCEAAAhCAAATySeBsMuzqY8VkOVY8tl/buhQglxRYViSHkeKDLvZD4s/1f/iB0cO9ZvTFP69+af6uvStxJmVRFeUk81VdAs/DqCZlEOsmKkVjhZpkvYpMYSKyo/vkNFfxPIn9WF5B1muzaC9HBBAgOZpshgoBCEAAAhCAQDoITK8wI5YUvKNSAySu1mTxU13EhytC2MiEtX887GkRwgdlc/f87y68rl3mKxs3637oinaB5zVZehXXo1pYjx/Ge82dWtU478flN2X51aNt5f6jo+xBoAMCCJAOYHEqBCAAAQhAAAIQ6AWBB09cTlwJ9T0SfD4qP1EgNUBkGZaIjyCKJf5DSRVCHfzUT5R+vBf9tdr4wtcrX3YpdyWaoxzYgiy9ksrnxtR0IapZFdVHd5WicmH3svfjmhQgbFQ9PyvCA+9HiyOvOyOAANkZP66GAAQgAAEIQAACXRBwNUAKOl66o6X0hzay/MpIBUAj+qPlAZFv/KJMbM++9buig5989f6fJUuvRIS4oHOX9crFfljn9ihJ4HlcjcZK9eW6H+qgxH4sVz0X2cIGgR4QoA5IDyDSBAQgAAEIQAACEGiDwDoxEVVCbfcF2taMxITroCA5eGMrgeiyBEuKgYQ/fnjkvW2029Ypv/Xlh18SBSGeD1WW4POKkcBzETxVpWp1pUuS86oa3Svvjhf3VszeqSkzoURwLNf9oOhgW5A5qS0CeEDawsRJEIAABCAAAQhAYKcEmg6Ea6/olTVAxsUDMiJZsEZcALpUQQ91IwhdfB/B6EhvMmB950b9zc9+ZelfS3X1soyiLGKnIg4XqXgu/peRsBZHcVQbGY/F+WFc2t3RW8qurnq+07FzPQQeEUCAPGLBHgQgAAEIQAACEOgvgSQF7zPSx5PqXftCvbsQSs1xJzzc8isnPqJAVl2JW0R+jC0c2NObGiD/+HMPvqADtSh+jEUJ5VgKxQsSRlFSeFBHhdr4rnpUr9Wj+2E53ls9Zi7fFR8JdT/6ey/kuHUESI4nn6FDAAIQgAAEIDAcAtXH3kqWY8Vj97SRIoQuBa+rAeLqfwSxSUTIoYOFnmTAuvq92reu/lVt3sV+GKsqEukuVc+bma9E/jjvh5G65620uxNu2dWqjeVXq3DwZscEECA7RkgDEIAABCAAAQhAoF0CZ9V0UgX9WHKBhIFLDRCXgjcIClKO0AWgm4KSGiAm+A+Ol4602+pm51XrtvoPf+veF2xgylJgpCKZtSqxDaTmR1CrjdRrJo6i8Xo9ehjHSdrdvdV7Jll6hfdjM6Qc7wEBBEgPINIEBCAAAQhAAAIQ6IRA9GBO18uNFLyuBkixIEuwSuL9cGl4ZfmVuCCCd78z3N9Jmxud+5W/qPzZzbu1u9YFnosIEYEjsR9xtR7GNVuVuh9RUep+PCo6ePnwSen6lRVN4f1YAYPdHhFAgPQIJM1AAAIQgAAEIACBtghMTyenxROu3Mce5eI/Yl0LbFyUCoROfEgGLCmDfmSysK+t9jY5yXk/Xvj9B6+LllmSL3zlJOhcAs+lwkhNxWGtFNUjF/sxOlk3E1J00Hk/1DVZfuXS7lL1fBOqHO4FAQRILyjSBgQgAAEIQAACENiawHIK3ge3LutoX6ERAyIZsGJdFfExqguSAsvFgGiXBcuoYP9EcGDrJrf+9Pe+svjFH74d33WxHy7uQwJMEu+HloRXSkd1U5Kq58VaXFnYE99eXDKNiucrvR9rY0G27o9PIdAuAQRIu6Q4DwIQgAAEIAABCHRN4FEK3qSJG0pFFa3H6w+lAKFkwZL4D5Ok3xUniDVJFqzJiaDrJVj3l8y9F37//p9KX2UpOFiW3t1rVdwtjbS7cT2KZPlV5cFEXByP7eg+OeXgbbwfXc8vF3ZCAAHSCS3OhQAEIAABCEAAAt0SSDSIS8F7UhlJwRuPLyQZsEqSAWvExYC4+A8Vy7os5wUxwZ4x3bUA+T9eW/q/lXg+rJK4D+f9kKVXUuAwCT634v0YjUrRWGF37DJf3Za6HxOHH6wQH8kAm4qp28FyHQQ2J4AA2ZwNn0AAAhCAAAQgAIHeETh/Pll25YoQHpJW91YPuNS7sgRLu1ogQWDi0BUfFAXismGFE7uCrmJA/vpv69//53/08IqydlHFasnV/aiFUTkMgkpdh1UbjtTjsWpUXqjH90qHkrofs9emVwgOAs97N+m0tBGBwkYHOQYBCEAAAhCAAAQg0GsCZ1c1GI+Jn0OUhpIgdCtLsJz2cAHoEnkR/kcnu0/B+5nXlv5YyghK4LlUFRThIXEl1TAsVqqmWi/GKhqJgnikvDs275ByIHvfsBPqSatc7Y8k8HyVibyBQF8I4AHpC1YahQAEIAABCEAAAusJJDVAjj+p6nsCqf1xX5fKZQlA17rgll+NyI+8yrIpCUAPuypC+J0b9e987qtLbxhtKlZ+XO0PLbEfxbqpu8xX8WgtkvofcUUy8LqlV6O3nrRJ3Y9lU/F+LKNgp28E8ID0DS0NQwACEIAABCAAgbUEplX1zlu6FO/VqiZ1QHZZPWJqQaxKskAqDmwQy0opHT75d0YOr72ynff/6HP3/kDiPcTrYcvGxJWwEErgubg+JPNVqTgaFWMTlSQBr6otmsrhY+L9EM8H3o920HJODwngAekhTJqCAAQgAAEIQAACWxKYdp8ekwxYb2vJvKsl8642hZIEoEeBGZE1WG4JlnhAdo/qXVu2s8GHV79X+9a3/6p+ywZKxIepSEBJ2cTiAYmDmizxqruq57XFWvxAAs9vTER29NZlvB8bcORQ/wkgQPrPmB4gAAEIQAACEMg3gdU1QKQKulIHlJGwjziQ2HOJ/yi4AiCxq0PoaoCEwXsOjRzrBJkrOvgPf+veF0S8lJU15dCWynFBsl7JsisdRjVTHIlGl6J4ojARu6KDpQPH7OUk8xWxH51w5tzeEECA9IYjrUAAAhCAAAQgAIFNCDQTTF17RYTHSTlnSk2OB3q8JOl3JeajIBmwXAre0KXglUro8i7cpKFND3/tL6p/cuvt6I6yI4su65UNY/F+6IqU+qhW41otiAo1M1aJqqVq7LwfB2dnper5tBh2vtkmsR+bwuWDnhNAgPQcKQ1CAAIQgAAEIACBNQTOuRS8rgaIUof23dBRVdLvSgpe996l4XXiw4kQlwXL1QE5ciB8j/usna1Wt5VPXrr/FRd0HojwsKpQDoKoosTz4QLPS1EhGo9qUbk0EZfuRnZv9Z6ZTYoOOu/HWREhiRntdMU5EOgJAQRITzDSCAQgAAEIQAACENiegKsBotRRFY/dS4oQugxYNpQfMyIuCIn/kCCQowcKHWXA+uzXyv9y/m58V5REUnTQZb2KTFxzsR9Kig6aUj2qF2rxeFw3txeXzMSbUnQw2c63DG6+b73lFQL9JUAWrP7ypXUIQAACEIAABCAgBM4ql4L39vS0UvduiEQIdEkSXwVSpDzWo+L9cNKjEYT+7/9kqe0MWPeXzMKvv3r/6+JLkXS7oQSf64oJoqoq6Joom1qxVokqthjV9C5z8MGiHd1XtrPq9oqq53g/uD0HTwABMnjm9AgBCEAAAhCAQE4JuBS8teq4aIUJZaK6VoVRyYBVlxogkgArkkKE4rbYOx60nQHrt2cXk8Bz8Z6UJd1uJZDAc1vX4vnYVbNhtS5Jd6OxUimWSBBze2rJHFQnJe2u/DwqOoj3I6f34jCHzRKsYdKnbwhAAAIQgAAE8kPAeT+am3EpeCUCPYn/EP1hIwk9N5ITS5Zh/RtH2qsB8jc/iq//b19c/JbW4kYRz4cUMRTvh3hCwrBWlbofo6YYxWPVqLxwI75z+JCIjycNRQdbM8DrMAkgQIZJn74hAAEIQAACEMg6geU1Tg9uXdbRg4KulwNZdLUYxNWqVEF3K6WUeEFUIKEg2oor48De4EA7UH7ny0t/JFHrZblGfqTmh6t6LrEftUJUK8ZxZKN6VL6/Ox5/x35TuPOWPXhNgs6Pk3a3Hbac018CCJD+8qV1CEAAAhCAAARyTaC5wilJwdsAEU/c0aamdUk8IAUt3g9XA0SyYLkaICIP9OTu7QXIW7eiN37vaw//0rjMV1ZVwiCW5VdBVYp+1JUJa6MSeF4bqcel/bGZTzJfHTOvrJoH0u6uwsGbgRJAgAwUN51BAAIQgAAEIJA7As0UvJW7u/ShfQUd7X6njqUGiImc50NS8Erch7IN74fLhLVnNNi/HaN/9Mq9z8s5iyIjFmOll5wXxJiooqv16qgeqT8MRur12nj09vfrZlxiPyYOr/R+ID6248vn/SVAEHp/+dI6BCAAAQhAAAK5J3B2FYFJWYK1KEEbrtqgLJuSSoQjUqw8Fv+H5LKSR8O7d+ktBchffL/+jatv1eflcqn5IZmvAltRxlU91zXRMXUTR9FodTxWqmKqjx01o7cu29m7IkBekR82CKSAAB6QFEwCJkAAAhCAAAQgkG0CLgWvOv5kMsiouqAlU5W2sgSrUQNEaSviw8V//DtPFLeM/6hFtvyrv7nwWbf0SsRGJVmCFQQVHUswiRQejIuScncpiiuFKP7h3diWDrxhLx+Wuh8u9iPZ8H5k+07zY3QIED/mCSshAAEIQAACEPCcQJKCdzHUat8+NVp0S7C0HhEPiJV1WE58WEmB9RPvLmzp/fjTf119/ead6K4Sz4es36rIJVUXeO4yX6lqvT4W1uujYS0efWdkRh9WxPshTpJr0yI+losOek4R87NAAAGShVlkDBCAAAQgAAEIpJvA9CPz4qoTH2UtDhDJglVPsmAlZQjllOM/NvLuR2eu3nPej0++ev/LkvGqIi1UrASeJ1XPVVANYhEgoj5qS3XxfkzEE3NVU9pds5dd1fMk89VZESF4P1YT5d2wCCBAhkWefiEAAQhAAAIQyDqB5RS8Sk3LWI+p+p5Ax9X7SQ0QN3hbkLgPcYW4fbeNl4Kxxt76//7B1yufu3nH3k1S74r3Q4LPq84DMio1P5SOJPajFJULuxPvx42JKKl6rg5K1XO8H+thcmSoBAhCHyp+OocABCAAAQhAILsEmmEXkoL3wb4f11HtgFYlKXK+d69SCw+UDWpSEb0ow48SBNooe3h/4e9sxGOxYu/8L7+38FUltT7EkSGxH0EliHRFQklqklCrbkYqkazDisd+pOOJB1WjisfM5TdnrZp+pln1fFnjbNQ8xyAwUAJ4QAaKm84gAAEIQAACEMgVgUSDPCNDPqnU1JSKlwK9u/ogCUA3hVIShK6UPA/WSsqBWDNaNKJQ1m+f/ZPFfyHiY0nOW7KqUA6l8GAYiBdEAtCrI4WaCJl6NDJav/+ed8W3F6fM5bty9vS0Uedc8Hmy9Kqphta3zREIDJoAAmTQxOkPAhCAAAQgAIH8EDh/ftn1EN27kexLyHjy6qqgq1pNWLiCIK4SSGwP7i38m2vh/PBe9Jef+oMHX3dZryRZViWIY1l+FVTrEnheknofseTdjeNqVJqPGxXPj4v4oOL5Woy8TxEBBEiKJgNTIAABCEAAAhDIJoHK3TcS0RHtfjt5NRKBnoy0KEuwgoKNjbXGBFK7Y/32ua8tfU7KhlRc1ivjYj9GdFUVYhEfRuI+4mgs2hWV7++O335H3ZR+cMzOXmul3HVtEXi+nihHhk2AGJBhzwD9QwACEIAABCCQIwKuzEdVagTKi0gQHdes+CuknqAyZ/6TyZ9YC+LmnfjP//kXH3zLeT+sLlRCG1WtsTVli7VyVK8HJowCE0Wl/eIHqR41B533Q2LbG0uv1rbGewikgwAekHTMA1ZAAAIQgAAEIJBJAmc3HFUQSjJd9xNZKf9RMIEKzeSEXhf/8cnP3f/fnfjQrt6Hiqsu85WOg5oK4npJig7Gu3ZFrujg27HzfryB92ND2hxMGwEESNpmBHsgAAEIQAACEMgWAVcFfYMtiEq2Ho7YuCCrr2Ibv+fwyOMrT/v+30Zfev0vqjdMUKiIQpG4j1jS7gZVV3TQ6hFZfhVF1SiKkqKDUcVc2ydFB4n9WImQ/ZQSQICkdGIwCwIQgAAEIACBLBK4oySlrtV1a+u2bAraxmFkYxuG0VhRL9cAiWK1+KsX7/1TKZJe0ZEIj0iKDYr3ox7HiffDBZ5HUS0qxbG5ow6Z0gFZynX4pGS6Ot+ERuxHFu+erIyJGJCszCTjgAAEIAABCEAg9QQKD/dbtaeqAhEgVpVsIM4PE4SxhKBH+yeC97QG8N2b9c++8Tf1t0MJ+ogCXbNSbDBwS69C+dFhPaqXouj+/Xjv+Iip3nnLXquK9+OuxH68klQ8bzXDKwRSSQAPSCqnBaMgAAEIQAACEMgMgYPTK2pw3FZBRaLIzagZCSWHleTUNaYSFcWzsaukH3NjrtXs/CdfefDbrtaHqBSp9xFUwmC0EsmrjlzNj3p9byA/4+PRnVrV7K0eM+ru9yT17vlWP63XzCBkINkigAckW/PJaCAAAQhAAAIQSCGB0X1P2sW7czZ8xwE7EhZNtVK3dXF+2MjEpWJBQtFDXSzoQ870b/91/Tf+1fXqnWCkIGe4MulBXWqFiOdDan6I40NLzY96KYjfLsR2710pOjgnng8qnqdw1jFpMwIIkM3IcBwCEIAABCAAAQj0jMBlVZg4aUd2z9vCHfFrVGOp+VEKgt21urIF9Z8/PXbEdRVF9tZ/9am7nysVtaTVjYzU+xCJ4ioVRhL+EUSxkdVX5Wq8u1Cyo6WjZvTvifjYJz9/X34aW+u1+ZYXCKSPAEuw0jcnWAQBCEAAAhCAQGYINILCJ5IA8bdU8V5sHx6ITS0ci+uy/Kq2JE4OCSj/u+8N3+WG/LW/rP43oQ0l2Dys6TCqafcqy66Mq3iua/VafSzaXdgTu6VXLu3u5d8V4fFGS3wQeJ6Z2ybjA0GAZHyCGR4EIAABCEAAAkMkcE6Cwl1qXNlKP6jZ0t2jNnxobFEiP0bDKJb1V5JLN44ndxXGKjX7Z//1/3r3qzUJOA91VK2r8apbdmV3R/VI/j8u4mOX1Pz44d3Yji9OmWu3/9aog9L2uZYAGeI46RoCHRBAgHQAi1MhAAEIQAACEIBANwRmrynr4kBuTCg7LkUDH8piqpo4NcZEWFg1Uv/RvXjuzRv1X0sEh4rq7tUE7lWWXt114qOaFBy8V6rGow8rZtQtuzp4W8RNK/Ac70c388I1wyGwYWGc4ZhCrxCAAAQgAAEIQCBrBKwWD4VW15SePq707WtvBIvjY8GBYimoFArB6MSDsHa/IKEggY5HtZZ1WTocMTaUWiEPi+Ip2ROZh3aP2b1QTzwfo49VzNEDx2InaB4VHUy+zhH7kbVbJ8PjQYBkeHIZGgQgAAEIQAACwyYgAsRtTRFyct/l4F5pb1D5wWjw7qNKLYYjwUQQBlF5QRZdHVj+XiYx5nZh0djS/tiM3DfWxXwUJiLrUu5evqsk5e7KpVd4P4Y9y/TfGQGWYHXGi7MhAAEIQAACEIBABwSWNYVc84q6/OaDREQ4T8b83ShZjlUR70a5NBHXy7Wovkd+5DWqVqP9eyvR/h+V43ulQ7GL+dhbvWcuH17p+XBmID46mAxOTQmBlf8qUmISZkAAAhCAAAQgAIEsEVjtBVG3Z/XJJyZ05e4uXX2sqKMHBT01pVT13pR8L7uhSnuP2rm5OUnbO2VLByR25JayEyI8Hi27Oi9wliues/QqS7dKTsaCAMnJRDNMCEAAAhCAAASGSWClCHlFq9sH9fT0tHpwS4kQeUOr40+q6p23ku9lpQPHRFS8oUZvPdkQHs7sVTEf7kByKuLDoWDzjgACxLspw2AIQAACEIAABDwkIN+5mnrBxYO4TQLTnTfECRG3Pbh1OTneqBkyq2avTTcuaKbxfZRuNzkN8ZFQ4z8+Emj8A/DRcmyGAAQgAAEIQAAC3hFoekLUecmOdbZh/TXxiKhn1ozkFaWOP9MQGavqfBDzsQYUbz0kgADxcNIwGQIQgAAEIAABnwm0REhzDOdEjCRbU5C4/VWio/EpAectDrz6TgAB4vsMYj8EIAABCEAAAp4SWCNENh0FXo9N0fABBCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhCAAAQgAAEIQAACEIAABCAAAQhAAAIQgAAEIAABCEAAAhDoI4H/H9ZM4sWVD4JuAAAAAElFTkSuQmCC\",\n      \"created\": 1774109179865,\n      \"lastRetrieved\": 1774109179865\n    }\n  }\n}"
  }
]